bundle produces different Gemfile.locks

[alex-tan]

Describe the problem as clearly as you can

Using the same version of bundler, the Gemfile.lock is different for unknown reasons.

diff --git a/Gemfile.lock b/Gemfile.lock
index 80fbf03b8b..60648301cb 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -104,19 +104,10 @@ GIT
       htmlentities
       rails (>= 3.2.0)
 
-GEM
-  remote: [redacted]
-  specs:
-    sidekiq-ent (1.8.1)
-      einhorn (= 0.7.4)
-      sidekiq (>= 5.2.3)
-      sidekiq-pro (>= 4.0.4)
-    sidekiq-pro (4.0.5)
-      concurrent-ruby (>= 1.0.5)
-      sidekiq (>= 5.2.1)
-
 GEM
   remote: https://rubygems.org/
+  remote: [redacted]
+  remote: [redacted]
   specs:
     Ascii85 (1.0.3)
     actioncable (6.0.4.8)
@@ -752,10 +743,19 @@ GEM
       rack (~> 2.0)
       rack-protection (>= 1.5.0)
       redis (~> 4.5, < 4.6.0)
+    sidekiq-ent (1.8.1)
+      einhorn (= 0.7.4)
+      sidekiq (>= 5.2.3)
+      sidekiq-pro (>= 4.0.4)
+    sidekiq-pro (4.0.5)
+      concurrent-ruby (>= 1.0.5)
+      sidekiq (>= 5.2.1)
     sidekiq-prometheus-exporter (0.1.13)
       sidekiq (>= 3.3.1)
     sidekiq-undertaker (1.0.1)
       sidekiq (>= 5.2, < 7)
+    signer (0.1.1)
+      actionpack (>= 6.0)
     simplecov (0.21.2)
       docile (~> 1.1)
       simplecov-html (~> 0.11)
@@ -852,12 +852,6 @@ GEM
       nokogiri (~> 1.8)
     zeitwerk (2.6.0)
 
-GEM
-  remote: [redacted]
-  specs:
-    signer (0.1.1)
-      actionpack (>= 6.0)
-
 PLATFORMS
   ruby

Did you try upgrading rubygems & bundler?

No the version is Bundler version 2.3.20 (2022-08-10 commit 4fd2813f54)

Post steps to reproduce the problem

Unclear because the same version of bundler leads to different results on different machines.

Which command did you run?

bundle

What were you expecting to happen?

Gemfile.lock doesn't change.

What actually happened?

Gemfile.lock changed. It appears it sometimes groups sources together, other times it splits them up.

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

Redacted for now.

[deivid-rodriguez]

This is not expected, recent Bundler versions always split sources when generating a Gemfile.lock file from scratch. They should also update existing Gemfile.lock files to split sections, unless frozen mode is configured, in which case Bundler will print a warning.

Please verify the above, you must be using an older Bundler version than you think on some machine.

[alex-tan]

@deivid-rodriguez I checked that the versions match on both machines. If it was using a different version and changing the lockfile wouldn't it update the BUNDLED WITH section? I'm asking the people who are having issues to see if there's any output about a bundler version mismatch when they run bundle.

[deivid-rodriguez]

Not always, if Bundler invocation doesn't need to rewrite the Gemfile.lock file for other reasons, it will not rewrite it just to change the BUNDLED WITH section. Please double check with your colleagues 👍.

[GermanDZ]

I'm suffering the same problem (with Sidekiq too) since a while ago (at least since Bundler 2.3.18).

Even doing a simple bundle update xxxx --no-conservative will update only the xxxx gem, but at the same time will move some specs from the main gem section to the Sidekiq section, producing later an error in CI because some gems (like actioncable) are not hosted in Sidekiq repo.

[alex-tan]

Yeah I confirmed there's no bundler version mismatch warning for those that are having issues.

[keldin-coding]

Yeah, we're also getting the same changes using an older version of Bundler (2.2.32) around this same thing. It doesn't happen every time, though. Once it happened for a single transitive dependency of something else entirely unrelated to Sidekiq and still tried to pull from that rubygems repo.

[deivid-rodriguez]

I have no idea what's going on :( Lock files with merged GEM sources should not be generated by any Bundler version higher than 2.2.18. If some higher version of Bundler is somehow generating these lockfiles, then I'd need some help with reproducing that because I have no clue of how that would happen.

[deivid-rodriguez]

I'm going to close this one for now since it's still unclear to me whether this an issue in the latest version, or somehow people unintentionally using old versions that generated the old Gemfile.lock layout. If someone can provide repro instructions I'll be more than happy to reopen this and look into the issue.