summaryrefslogtreecommitdiff
path: root/spec/bundler/commands/lock_spec.rb
diff options
context:
space:
mode:
authorDavid Rodríguez <deivid.rodriguez@riseup.net>2023-03-09 17:34:17 +0100
committerHiroshi SHIBATA <hsbt@ruby-lang.org>2023-03-17 18:50:55 +0900
commitc65d7b4bea170ffe4811534ab33b231f7f57d69f (patch)
tree6094c572e17d1a2ed41ea4e7b3c06b552d72d79f /spec/bundler/commands/lock_spec.rb
parent0b9e51c4294ff938ef8c244f2ca502ec6c230a63 (diff)
downloadruby-c65d7b4bea170ffe4811534ab33b231f7f57d69f.tar.gz
When running `bundle lock --update <name>`, checkout locked revision of unrelated git sources directly
Since Bundler 2.4, we will try to checkout any branch specified in the Gemfile, while until Bundler 2.3 we would directly checkout the locked revision. This should not make any difference in most situations, but in some edge cases, like if the branch specified in the `Gemfile` has been renamed, but the locked revision still exist, it causes an error now while before it would update the lockfile without issues. I debated which behavior was best, since I was not sure. But my conclusion is that if the situation does not require expiring the lockfile source in favor of the Gemfile source, we should use the locked revision directly and proceed happily. So I restored Bundler 2.3 behavior. I think this is consistent with how yanked gems are handled, for example. Of course, if explicitly updating the git source itself, or all gems, we will still get any errors like missing branches related to the git source.
Diffstat (limited to 'spec/bundler/commands/lock_spec.rb')
-rw-r--r--spec/bundler/commands/lock_spec.rb38
1 files changed, 38 insertions, 0 deletions
diff --git a/spec/bundler/commands/lock_spec.rb b/spec/bundler/commands/lock_spec.rb
index f0c3537d2f..a148d6dd19 100644
--- a/spec/bundler/commands/lock_spec.rb
+++ b/spec/bundler/commands/lock_spec.rb
@@ -158,6 +158,44 @@ RSpec.describe "bundle lock" do
expect(out).not_to include("re-resolving dependencies because the list of sources changed")
end
+ it "updates specific gems using --update using the locked revision of unrelated git gems for resolving" do
+ ref = build_git("foo").ref_for("HEAD")
+
+ gemfile <<-G
+ source "#{file_uri_for(gem_repo1)}"
+ gem "rake"
+ gem "foo", :git => "#{file_uri_for(lib_path("foo-1.0"))}", :branch => "deadbeef"
+ G
+
+ lockfile <<~L
+ GIT
+ remote: #{file_uri_for(lib_path("foo-1.0"))}
+ revision: #{ref}
+ branch: deadbeef
+ specs:
+ foo (1.0)
+
+ GEM
+ remote: #{file_uri_for(gem_repo1)}/
+ specs:
+ rake (10.0.1)
+
+ PLATFORMS
+ #{lockfile_platforms}
+
+ DEPENDENCIES
+ foo!
+ rake
+
+ BUNDLED WITH
+ #{Bundler::VERSION}
+ L
+
+ bundle "lock --update rake --verbose"
+ expect(out).to match(/Writing lockfile to.+lock/)
+ expect(lockfile).to include("rake (13.0.1)")
+ end
+
it "errors when updating a missing specific gems using --update" do
lockfile @lockfile