`bundle check` corrupts gem's Gemfile.lock by moving gems between sources

[ZimbiX]

Describe the problem as clearly as you can

We have a private gem that depends on other gems: some public, some private.

We use a Dockerised development environment, and in the repo for this gem, as part of our Docker entrypoint, we have it install the bundle, but first run bundle check for a performant check to see if we need to do so:

bundle check || bundle install --jobs=100

Unfortunately, it seems that Bundler now corrupts the Gemfile.lock when we run bundle check after updating the gem's version. The command succeeds, but the public gems get moved to the private source in Gemfile.lock. This results in failure from the next bundle install which needs to install gems.

I had no idea that bundle check could modify the Gemfile.lock at all, let alone corrupt it.

As a workaround, we are now using bundle check --dry-run there, which actually doesn't modify/corrupt the Gemfile.lock.

Did you try upgrading rubygems & bundler?

Yes

Post steps to reproduce the problem

Given it's a sources issue, this seems to require running a secondary gem server to reproduce; I am not experienced in setting one up that's accessible from outside our organisation to create an easy reproduction =\ However, I have come up with minimal reproduction steps using two dependency-less gems for simplicity:

• Create a new gem, e.g.:

  bundle gem bundle-check-issue

• Make the gem bundle-able by commenting out, in the gemspec, the spec.metadata lines, TODO lines, and add spec.summary = ""

• Add a public gem dependency to the gemspec, e.g.:

  spec.add_runtime_dependency 'awesome_print'

• Add a private gem dependency to the Gemfile, e.g.:

  source 'https://rubygems.pkg.github.com/greensync' do
    gem 'dex-dispatch-engine'
  end

  but one that you have access to.

• Create a Gemfile.lock:

  bundle

• Update the version of the gem, e.g. on Linux:

  sed -i -E 's/[0-9.]+/9999/' **/version.rb`

• Run bundle check

  Resolving dependencies...
  The Gemfile's dependencies are satisfied
  

  Gemfile.lock has now been corrupted, and the next bundle install that needs to install awesome_print will fail:

  ➜ gem uninstall -a -I awesome_print
  Successfully uninstalled awesome_print-1.9.2
  
  ➜ bundle install                   
  Fetching gem metadata from https://rubygems.pkg.github.com/greensync/..
  Your bundle is locked to awesome_print (1.9.2) from rubygems repository https://rubygems.pkg.github.com/greensync/ or installed locally, but that version can no longer be found in that source. That means the author of awesome_print (1.9.2) has removed it. You'll need to
  update your bundle to a version other than awesome_print (1.9.2) that hasn't been removed in order to install.
  

Which command did you run?

Update the gem's version number, then:

bundle check

What were you expecting to happen?

Gemfile.lock not to be modified at all by bundle check, let alone corrupted

What actually happened?

Gemfile.lock was corrupted by bundle check:

diff --git a/Gemfile.lock b/Gemfile.lock
index 5afa4e9..6385ddb 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,17 +1,17 @@
 PATH
   remote: .
   specs:
-    bundle-check-issue (0.1.0)
+    bundle-check-issue (9999)
       awesome_print
 
 GEM
   remote: https://rubygems.org/
   specs:
-    awesome_print (1.9.2)
 
 GEM
   remote: https://rubygems.pkg.github.com/greensync/
   specs:
+    awesome_print (1.9.2)
     dex-dispatch-engine (0.7.0)
 
 PLATFORMS

Version which introduced the bug

The bug was introduced in Bundler 2.2.26, as determined using:

➜ v=2.2.25; gem install bundler -v $v; bundle _${v}_ install; git add .; sed -i -E 's/[0-9.]+/9999/' **/version.rb; bundle _${v}_ check; git diff Gemfile.lock; git checkout .
Successfully installed bundler-2.2.25
1 gem installed
Using awesome_print 1.9.2
Using bundle-check-issue 0.1.0 from source at `.`
Using bundler 2.2.25
Using dex-dispatch-engine 0.7.0
Bundle complete! 2 Gemfile dependencies, 4 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Resolving dependencies...
The Gemfile's dependencies are satisfied
diff --git a/Gemfile.lock b/Gemfile.lock
index c64da60..961321f 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    bundle-check-issue (0.1.0)
+    bundle-check-issue (9999)
       awesome_print
 
 GEM
Updated 2 paths from the index

➜ v=2.2.26; gem install bundler -v $v; bundle _${v}_ install; git add .; sed -i -E 's/[0-9.]+/9999/' **/version.rb; bundle _${v}_ check; git diff Gemfile.lock; git checkout .
Successfully installed bundler-2.2.26
1 gem installed
Using awesome_print 1.9.2
Using bundle-check-issue 0.1.0 from source at `.`
Using bundler 2.2.26
Using dex-dispatch-engine 0.7.0
Bundle complete! 2 Gemfile dependencies, 4 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Resolving dependencies...
The Gemfile's dependencies are satisfied
diff --git a/Gemfile.lock b/Gemfile.lock
index c64da60..a669110 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,17 +1,17 @@
 PATH
   remote: .
   specs:
-    bundle-check-issue (0.1.0)
+    bundle-check-issue (9999)
       awesome_print
 
 GEM
   remote: https://rubygems.org/
   specs:
-    awesome_print (1.9.2)
 
 GEM
   remote: https://rubygems.pkg.github.com/greensync/
   specs:
+    awesome_print (1.9.2)
     dex-dispatch-engine (0.7.0)
 
 PLATFORMS
@@ -22,4 +22,4 @@ DEPENDENCIES
   dex-dispatch-engine!
 
 BUNDLED WITH
-   2.2.25
+   2.2.26
Updated 2 paths from the index

If not included with the output of your command, run bundle env and paste the output below

Environment

Bundler       2.3.6
  Platforms   ruby, x86_64-linux
Ruby          2.7.3p183 (2021-04-05 revision 6847ee089d7655b2a0eea4fee3133aeacd4cc7cc) [x86_64-linux]
  Full Path   /home/brendan/.rbenv/versions/2.7.3/bin/ruby
  Config Dir  /home/brendan/.rbenv/versions/2.7.3/etc
RubyGems      3.3.6
  Gem Home    /home/brendan/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0
  Gem Path    /home/brendan/.gem/ruby/2.7.0:/home/brendan/.rbenv/versions/2.7.3/lib/ruby/gems/2.7.0
  User Home   /home/brendan
  User Path   /home/brendan/.gem/ruby/2.7.0
  Bin Dir     /home/brendan/.rbenv/versions/2.7.3/bin
Tools         
  Git         2.35.1
  RVM         not installed
  rbenv       rbenv 1.2.0
  chruby      not installed

Bundler Build Metadata

Built At          2022-01-26
Git SHA           056f64c33a
Released Version  true

Bundler settings

gem.changelog
  Set for the current user (/home/brendan/.bundle/config): false
gem.ci
  Set for the current user (/home/brendan/.bundle/config): false
gem.coc
  Set for the current user (/home/brendan/.bundle/config): false
gem.linter
  Set for the current user (/home/brendan/.bundle/config): "rubocop"
gem.mit
  Set for the current user (/home/brendan/.bundle/config): false
gem.test
  Set for the current user (/home/brendan/.bundle/config): "rspec"
https://rubygems.pkg.github.com/greensync/
  Set for the current user (/home/brendan/.bundle/config): "ZimbiX:[REDACTED]"
jobs
  Set via BUNDLE_JOBS: 100

Gemfile

Gemfile

source 'https://rubygems.org'

source 'https://rubygems.pkg.github.com/greensync' do
  gem 'dex-dispatch-engine'
end

gemspec

Gemfile.lock

PATH
  remote: .
  specs:
    bundle-check-issue (0.1.0)
      awesome_print

GEM
  remote: https://rubygems.org/
  specs:
    awesome_print (1.9.2)

GEM
  remote: https://rubygems.pkg.github.com/greensync/
  specs:
    dex-dispatch-engine (0.7.0)

PLATFORMS
  x86_64-linux

DEPENDENCIES
  bundle-check-issue!
  dex-dispatch-engine!

BUNDLED WITH
   2.3.6

Gemspecs

bundle-check-issue.gemspec

# frozen_string_literal: true

require_relative "lib/bundle/check/issue/version"

Gem::Specification.new do |spec|
  spec.name = "bundle-check-issue"
  spec.version = Bundle::Check::Issue::VERSION
  spec.authors = ["Brendan Weibrecht"]
  spec.email = ["brendan@weibrecht.net.au"]

  spec.summary = ""
  # spec.summary = "TODO: Write a short summary, because RubyGems requires one."
  # spec.description = "TODO: Write a longer description or delete this line."
  # spec.homepage = "TODO: Put your gem's website or public repo URL here."
  spec.required_ruby_version = ">= 2.6.0"

  # spec.metadata["allowed_push_host"] = "TODO: Set to your gem server 'https://example.com'"

  # spec.metadata["homepage_uri"] = spec.homepage
  # spec.metadata["source_code_uri"] = "TODO: Put your gem's public repo URL here."
  # spec.metadata["changelog_uri"] = "TODO: Put your gem's CHANGELOG.md URL here."

  # Specify which files should be added to the gem when it is released.
  # The `git ls-files -z` loads the files in the RubyGem that have been added into git.
  spec.files = Dir.chdir(File.expand_path(__dir__)) do
    `git ls-files -z`.split("\x0").reject do |f|
      (f == __FILE__) || f.match(%r{\A(?:(?:bin|test|spec|features)/|\.(?:git|travis|circleci)|appveyor)})
    end
  end
  spec.bindir = "exe"
  spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
  spec.require_paths = ["lib"]

  # Uncomment to register a new dependency of your gem
  # spec.add_dependency "example-gem", "~> 1.0"

  spec.add_runtime_dependency 'awesome_print'

  # For more information and examples about making a new gem, check out our
  # guide at: https://bundler.io/guides/creating_gem.html
end

[ZimbiX]

To clarify a little, in our project, it only moves about a quarter of the gems from https://rubygems.org/ in the Gemfile.lock. I haven't determined what makes a gem stay vs move.

[deivid-rodriguez]

#5344 should fix this!

[taylorthurlow]

I'm not entirely sure this was fixed, or at least some version of this problem is still lingering. I can confirm I am having the same problem on bundler 2.5.21 and 2.2.26, but not on 2.2.25. Working on cleaning up my reproduction.

[taylorthurlow]

Ok, I managed to distill this down to something really simple. Start with a Gemfile with two sources - you do NOT need to be able to correctly authenticate with this second gemserver in order to replicate the issue, as long as you hand-copy the Gemfile.lock along with it. I tried to come up with a gemserver that is publicly accessible that I was comfortable leaving in an issue like this and I could not find one.

source "https://rubygems.org"

source "https://enterprise.contribsys.com/" do
  gem "sidekiq-ent"
  gem "sidekiq-pro"
end

gem "sidekiq"

GEM
  remote: https://enterprise.contribsys.com/
  specs:
    sidekiq-ent (7.3.1)
      einhorn (~> 1.0)
      gserver
      sidekiq (>= 7.3.0, < 8)
      sidekiq-pro (>= 7.3.0, < 8)
    sidekiq-pro (7.3.1)
      sidekiq (>= 7.3.0, < 8)

GEM
  remote: https://rubygems.org/
  specs:
    concurrent-ruby (1.3.4)
    connection_pool (2.4.1)
    einhorn (1.0.0)
    gserver (0.0.1)
    logger (1.6.1)
    rack (3.1.7)
    redis-client (0.22.2)
      connection_pool
    sidekiq (7.3.2)
      concurrent-ruby (< 2)
      connection_pool (>= 2.3.0)
      logger
      rack (>= 2.2.4)
      redis-client (>= 0.22.2)

PLATFORMS
  ruby

DEPENDENCIES
  sidekiq
  sidekiq-ent!
  sidekiq-pro!

BUNDLED WITH
   2.5.21

This Gemfile and Gemfile.lock are both valid and have no issues. To replicate, add a gem to the Gemfile, and do not run bundle install.

source "https://rubygems.org"

source "https://enterprise.contribsys.com/" do
  gem "sidekiq-ent"
  gem "sidekiq-pro"
end

gem "sidekiq"
gem "ruby-lsp"

Run bundle check, and observe the change to Gemfile.lock, which moves the dependencies to the wrong source:

diff --git a/Gemfile.lock b/Gemfile.lock
index 65dfc42..f771ec2 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,6 +1,10 @@
 GEM
   remote: https://enterprise.contribsys.com/
   specs:
+    language_server-protocol (3.17.0.3)
+    prism (1.1.0)
+    rbs (3.6.1)
+      logger
     sidekiq-ent (7.3.1)
       einhorn (~> 1.0)
       gserver
@@ -8,6 +12,7 @@ GEM
       sidekiq-pro (>= 7.3.0, < 8)
     sidekiq-pro (7.3.1)
       sidekiq (>= 7.3.0, < 8)
+    sorbet-runtime (0.5.11600)
 
 GEM
   remote: https://rubygems.org/
@@ -20,6 +25,11 @@ GEM
     rack (3.1.7)
     redis-client (0.22.2)
       connection_pool
+    ruby-lsp (0.19.1)
+      language_server-protocol (~> 3.17.0)
+      prism (>= 1.1, < 2.0)
+      rbs (>= 3, < 4)
+      sorbet-runtime (>= 0.5.10782)
     sidekiq (7.3.2)
       concurrent-ruby (< 2)
       connection_pool (>= 2.3.0)
@@ -32,6 +42,7 @@ PLATFORMS
   ruby
 
 DEPENDENCIES
+  ruby-lsp
   sidekiq
   sidekiq-ent!
   sidekiq-pro!

[taylorthurlow]

@deivid-rodriguez - Hope you don't mind a ping on this one seeing as you were responsible for the original fix.

[deivid-rodriguez]

@taylorthurlow Unfortunately I cannot reproduce the issue. Following your steps I get

$ bundle check
Bundler can't satisfy your Gemfile's dependencies.
Install missing gems with `bundle install`

Which makes sense since I don't have any of those gems installed.

I assumed in your system you do have them installed already, so I tried to simulate that situation with a bundler spec, but everything worked correctly (gem got added to the right place in the Gemfile.lock file).

[taylorthurlow]

@deivid-rodriguez thanks for attempting to reproduce - I'll try to write a bundler spec. Did the gem you added have any dependencies? In my case the gem I am adding does get added to the correct location, its the dependencies of the new gem that get added to the wrong spot.

[taylorthurlow]

@deivid-rodriguez I've got a (slightly sloppy) bundler spec which reproduces the issue:

  context "with scoped and unscoped sources" do
    fit "does not corrupt lockfile" do
      build_repo2 do
        build_gem "foo"
        build_gem "wadus"
        build_gem("baz") { |s| s.add_dependency "wadus" }
      end

      build_repo4 do
        build_gem "bar"
      end

      # Add all gems to ensure all gems are installed so that a bundle check
      # would be successful
      install_gemfile(<<-G, artifice: "compact_index_extra")
        source "https://gem.repo2"

        source "https://gem.repo4" do
          gem "bar"
        end

        gem "foo"
        gem "baz"
      G

      correct_lockfile = lockfile

      # Remove "baz" gem from the Gemfile, and bundle install again to generate
      # a functional lockfile with no "baz" dependency or "wadus" transitive
      # dependency
      install_gemfile(<<-G, artifice: "compact_index_extra")
        source "https://gem.repo2"

        source "https://gem.repo4" do
          gem "bar"
        end

        gem "foo"
      G

      # Add "baz" gem back to the Gemfile, but _crucially_ we do not perform a
      # bundle install
      gemfile(gemfile + 'gem "baz"')

      # Bundle check, which we expect to succeed, but break the lockfile
      bundle :check

      broken_lockfile = lockfile

      # Observe that the "wadus" transitive dependency is moved from the "repo2"
      # section of the gemspec to the "repo4" section, which is incorrect
      expect(correct_lockfile).to eq(broken_lockfile)
    end
  end

There's probably a better way to use the bundler spec helpers to do what I did here. Here are the steps and the thoughts behind the spec:

• Include all (4) dependencies in a Gemfile and bundle install, so they are fetched stored locally
  • foo and bar are largely not relevant and belong to repo2 and repo4, respectively
  • baz is the "additional dependency" we are adding to the Gemfile as part of reproducing the issue, belonging to repo2
  • wadus is a dependency of baz and therefore a transitive dependency of the Gemfile as a whole, and not included anywhere in our Gemfile, and belongs to repo2
• Note that the wadus dependency is correctly added to the repo2 section of the lockfile
• Remove baz from the Gemfile and perform a bundle install to get our lockfile into a clean state with no baz or wadus.
• Add gem "baz" to the Gemfile, and do not perform a bundle install
• Run bundle check, and note that the wadus dependency is now incorrectly located in the repo4 section of the lockfile

I'm not entirely sure what the real outcome should be here (other than not putting dependencies where they don't belong), given that a change was made to the Gemfile before running bundle check.

[deivid-rodriguez]

Thanks for the repro, I'll have a look, but just in case I forget, can you open a WIP PR with your failing test, or a alternatively a new issue about this?