-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundler 2: [Prerelease] Add version resolver #3319
Conversation
|
||
let(:dependency_files) { project_dependency_files("bundler2/bundler_specified") } | ||
|
||
it "returns nil as resolution returns the bundler version installed by core" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bummer, it doesn't seem like we can currently update bundler at all.
When running a dry-run to update a gemfile with bundler v1 it tries to go to v2 even though the project has been bundled with v1, it looks like it falls through here atm: https://github.com/dependabot/dependabot-core/blob/main/bundler/helpers/v1/lib/functions/version_resolver.rb#L24 because bundler
isn't listed as one of the gems in the definition.
When running the v2 helpers, bundler
is listed as a gem but we return nil if the gem name is bundler
, I think this is the best thing for now as the "resolved version" is core's bundler version, not the latest resolvable version.
|
||
let(:dependency_files) { project_dependency_files("bundler2/requires_bundler") } | ||
|
||
pending "resolves version" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These specs require the LatestVersionFinder and all the dependency source native helpers to be added so left these as pending until we have that merged in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be able to remove pending
once this is in #3327
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do this downstream in a separate PR 👍
let(:dependency_files) do | ||
project_dependency_files("bundler1/imports_gemspec_version_clash_old_required_ruby_no_lockfile") | ||
end | ||
let(:gemfile_fixture_name) { "imports_gemspec_version_clash" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused
end | ||
let(:current_version) { "3.0.1" } | ||
|
||
it "raises a DependencyFileNotResolvable error" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously it looked like bundler v1 ignores the minimum ruby version in the gemspec
(see spec above), I think this new behaviour is correct as the currently installed version of statesman
doesn't satisfy the ruby version in the project gemspec.
@@ -2074,98 +2074,4 @@ | |||
it { is_expected.to eq(false) } | |||
end | |||
end | |||
|
|||
context "with bundler 2 support enabled" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these specs fail because the v2 version resolver is used and returns errors.
@@ -1708,29 +1708,4 @@ | |||
end | |||
end | |||
end | |||
|
|||
context "with bundler 2 support enabled" do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These specs fail because the v2 version resolver is used and returns errors.
@@ -8,11 +8,11 @@ def index | |||
if ruby_version | |||
requested_version = ruby_version.to_gem_version_with_patchlevel | |||
sources.metadata_source.specs << | |||
Gem::Specification.new("ruby\0", requested_version) | |||
Gem::Specification.new("Ruby\0", requested_version) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it changed here: rubygems/rubygems@4e950f5
end | ||
end | ||
|
||
context "when bundled with v2 and requesting a version that requires bundler v1", :bundler_v2_only do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jurre looks like this spec is not actually raising, not sure there's anything wrong with that though so probably just a bogus test case that can be removed.
let(:dependency_files) { project_dependency_files("bundler2/requires_bundler") } | ||
|
||
pending "resolves version" do | ||
expect(subject.version).to eq(Gem::Version.new("3.0.0")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be expect(subject[:version]).to eq(Gem::Version.new("3.0.0"))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cheers 👍
Up until the Bundler 2 upgrade, when in the context of updating a library, dependabot would first try locking the Ruby version according to the minimum ruby requirement specified in the gemspec (if any). If that fail, dependabot would retry without any ruby version locking by detecting a specific error message raised by Bundler. This feature was introduced by fcd5682. However, when the upgrade to Bundler 2 happened, the related spec started failing, because the string to look for within Bundler's error message was not updated to match what Bundler 2 was raising (error message was changed upstream at rubygems/bundler#6647). Instead, the spec was updated to match the new result (see dependabot#3319 (comment)). In the spec, dependabot is updating a Gemfile including ```ruby gem 'statesman', "~> 3.0.0" ``` in combination with a gemspec including ```ruby required_ruby_version ">= 1.9.3" ``` Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support Ruby 1.9.3 already. The original dependabot behaviour was to ignore the preexisting mismatch and move on. That makes sense to me, there's some reasons why a library main have this situation. In my case, I have several Gemfiles testing different major versions of my dependencies (Rails, in particular), and some of them don't support the oldest Ruby supported by my gem (my Rails 7 gemfile does not support my oldest supported Ruby, 2.6). On a more pragmatic point of view, the old behavior didn't cause any reported issues that I know of, while the new behavior did bite my particular case. So this commit changes the expectation to what it used to be and updates the strings to look for in error messages to support both Bundler 1 and Bundler 2 error messages.
Up until the Bundler 2 upgrade, when in the context of updating a library, dependabot would first try locking the Ruby version according to the minimum ruby requirement specified in the gemspec (if any). If that fail, dependabot would retry without any ruby version locking by detecting a specific error message raised by Bundler. This feature was introduced by fcd5682. However, when the upgrade to Bundler 2 happened, the related spec started failing, because the string to look for within Bundler's error message was not updated to match what Bundler 2 was raising (error message was changed upstream at rubygems/bundler#6647). Instead, the spec was updated to match the new result (see dependabot#3319 (comment)). In the spec, dependabot is updating a Gemfile including ```ruby gem 'statesman', "~> 3.0.0" ``` in combination with a gemspec including ```ruby required_ruby_version ">= 1.9.3" ``` Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support Ruby 1.9.3 already. The original dependabot behaviour was to ignore the preexisting mismatch and move on. That makes sense to me, there's some reasons why a library main have this situation. In my case, I have several Gemfiles testing different major versions of my dependencies (Rails, in particular), and some of them don't support the oldest Ruby supported by my gem (my Rails 7 gemfile does not support my oldest supported Ruby, 2.6). On a more pragmatic point of view, the old behavior didn't cause any reported issues that I know of, while the new behavior did bite my particular case. So this commit changes the expectation to what it used to be and updates the strings to look for in error messages to support both Bundler 1 and Bundler 2 error messages.
Up until the Bundler 2 upgrade, when in the context of updating a library, dependabot would first try locking the Ruby version according to the minimum ruby requirement specified in the gemspec (if any). If that fail, dependabot would retry without any ruby version locking by detecting a specific error message raised by Bundler. This feature was introduced by fcd5682. However, when the upgrade to Bundler 2 happened, the related spec started failing, because the string to look for within Bundler's error message was not updated to match what Bundler 2 was raising (error message was changed upstream at rubygems/bundler#6647). Instead, the spec was updated to match the new result (see dependabot#3319 (comment)). In the spec, dependabot is updating a Gemfile including ```ruby gem 'statesman', "~> 3.0.0" ``` in combination with a gemspec including ```ruby required_ruby_version ">= 1.9.3" ``` Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support Ruby 1.9.3 already. The original dependabot behaviour was to ignore the preexisting mismatch and move on. That makes sense to me, there's some reasons why a library main have this situation. In my case, I have several Gemfiles testing different major versions of my dependencies (Rails, in particular), and some of them don't support the oldest Ruby supported by my gem (my Rails 7 gemfile does not support my oldest supported Ruby, 2.6). On a more pragmatic point of view, the old behavior didn't cause any reported issues that I know of, while the new behavior did bite my particular case. So this commit changes the expectation to what it used to be and updates the strings to look for in error messages to support both Bundler 1 and Bundler 2 error messages.
Up until the Bundler 2 upgrade, when in the context of updating a library, dependabot would first try locking the Ruby version according to the minimum ruby requirement specified in the gemspec (if any). If that fail, dependabot would retry without any ruby version locking by detecting a specific error message raised by Bundler. This feature was introduced by fcd5682. However, when the upgrade to Bundler 2 happened, the related spec started failing, because the string to look for within Bundler's error message was not updated to match what Bundler 2 was raising (error message was changed upstream at rubygems/bundler#6647). Instead, the spec was updated to match the new result (see dependabot#3319 (comment)). In the spec, dependabot is updating a Gemfile including ```ruby gem 'statesman', "~> 3.0.0" ``` in combination with a gemspec including ```ruby required_ruby_version ">= 1.9.3" ``` Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support Ruby 1.9.3 already. The original dependabot behaviour was to ignore the preexisting mismatch and move on. That makes sense to me, there's some reasons why a library main have this situation. In my case, I have several Gemfiles testing different major versions of my dependencies (Rails, in particular), and some of them don't support the oldest Ruby supported by my gem (my Rails 7 gemfile does not support my oldest supported Ruby, 2.6). On a more pragmatic point of view, the old behavior didn't cause any reported issues that I know of, while the new behavior did bite my particular case. So this commit changes the expectation to what it used to be and updates the strings to look for in error messages to support both Bundler 1 and Bundler 2 error messages.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked. So this removes them.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked. So this removes them.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked. So this removes them.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked. So this removes them, and then fixes the failures. One test was straightforward change from method to hash value. But the other was a logical change from expecting a raised error to expecting no error. However, this has been true since this code was originally committed (once #3327 was merged to make the test work): https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250 I considered removing it, but thought it didn't hurt to continue to keep it in to ensure no regressions... it is a `bundler 2` test, so still valid even after we drop support for `bundler 1`.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked. So this removes them, and then fixes the failures. One test was straightforward change from method to hash value. But the other was a logical change from expecting a raised error to expecting no error. However, this has been true since this code was originally committed (once #3327 was merged to make the test work): https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250 I considered removing it, but thought it didn't hurt to continue to keep it in to ensure no regressions... it is a `bundler 2` test, so still valid even after we drop support for `bundler 1`.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` marker, but that accidentally got overlooked. So this removes the `pending` marker, and then fixes the failures: 1. The first was a straightforward change from method to hash value. 2. The second wasn't raising the expected error... However, this has been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250) (once #3327 was merged to make the test work). So I deleted the test as it added no value.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` marker, but that accidentally got overlooked. So this removes the `pending` marker, and then fixes the failures: 1. The first was a straightforward change from method to hash value. 2. The second wasn't raising the expected error... However, this has been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250) (once #3327 was merged to make the test work). So I deleted the test as it added no value.
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged. From the first thread it looks like the intent was to remove the `pending` marker, but that accidentally got overlooked. So this removes the `pending` marker, and then fixes the failures: 1. The first was a straightforward change from method to hash value. 2. The second wasn't raising the expected error... However, this has been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250) (once #3327 was merged to make the test work). So I deleted the test as it added no value.
Add native helpers for bundler 2 version resolver.
Added two
pending
specs as they require theLatestVersionFinder
.TODO