dependabot should bump BUNDLED WITH in gemfile lock

[ojab]

Occasionally there are bugfixes and even security fixes, would be good to bump it.
While it wouldn't actually prevent using older bundler unless something like gem install --clear-sources bundler -v $(grep -A1 'BUNDLED WITH' Gemfile.lock | tail -1 | sed -e 's/[[:space:]]*//') during image build is used, it will provide visibility and nag people to perform an update.

[mobilutz]

I support this as well.
But because of another reason.

I am currently using bundler v2.1.4 in my repo, but dependabot does the bundle updates with the newest version.
This leads to a problem for CI run, and github-action uses the bundler version from Gemfile.lock and there are changes related to a higher bundler version that will fail in the lower one.

And I think code speaks for iteself!

v2.1.4 Gemfile.lock format:

...
GEM
  remote: https://rubygems.org/
  remote: https://gems.contribsys.com/
  specs:
    ...
    sidekiq-pro (5.2.3)
      sidekiq (>= 6.2.0)
    ...

BUNDLED WITH
   2.1.4

v2.2.26 (as an example to show the difference) Gemfile.lock format:

...
GEM
  remote: https://gems.contribsys.com/
  specs:
    sidekiq-pro (5.2.3)
      sidekiq (>= 6.2.0)

GEM
  remote: https://rubygems.org/
  specs:
    ...

BUNDLED WITH
   2.2.26

[ojab]

Yep, also saw this rubygems/rfcs#29 (comment)

[jurre]

Yeah this is a tricky one, the lockfile format was actually changed a good while back, but since recently bundler will also actively try to update you to the newest format. I believe the new format should work in 2.1.4 without problems (and would have that same format if created from scratch).

The reason I find this a little tricky is that definitely not everyone will want us to bump their bundler version in regular updates. For most scenario's where your lockfile format is already up to date (or you're still on bundler 1) you shouldn't notice that we run a different version of bundler under the hood.

Ideally I think we'd run updates using the bundler version as specified, and open separate PRs to update the package manager version, but the latter is something we currently don't do for any ecosystem. And tbh given our current setup this will be a fair amount of work that we likely can't get to in the near term. Now I don't want to let perfect be the enemy of good, but I think that maybe keeping things as is for now might be the best compromise?

cc @asciimike curious to hear your thoughts

[rickselby]

I've seen this issue too (from a 2.1.4 lockfile).

Running bundle update locally on a dependabot-generated branch does work, but it resets the Gemfile.lock to the original format. In our workflows, the ruby/setup-ruby action fails when trying to install the gems, as deployment is set to true, and running install would try to change the lock file:

$ bundle config --local deployment true
$ bundle update
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.

If this is a development machine, remove the /home/.../Gemfile freeze 
by running `bundle config unset deployment`.

The list of sources changed

[mobilutz]

@jurre
I think that this is the best idea you mentioned.

Ideally I think we'd run updates using the bundler version as specified ...

This will at least not change the format of the Gemfile.lock when just a dependency is being updated.
And bundler 2.1.4 does NOT work with a Gemfile.lock which comes from 2.2.26. See the error below we alway get from CI runs in the ruby/setup-ruby step on dependabot PRs:

  You are trying to install in deployment mode after changing
  your Gemfile. Run `bundle install` elsewhere and add the
  updated Gemfile.lock to version control.
  
  If this is a development machine, remove the
  /home/runner/work/XXX/YYY/Gemfile freeze
  by running `bundle config unset deployment`.

[jurre]

And bundler 2.1.4 does NOT work with a Gemfile.lock which comes from 2.2.26. See the error below we alway get from CI runs in the ruby/setup-ruby step on dependabot PRs:

Ah, that's good to know, it's a bummer that a minor version update of bundler breaks compatibility in this way :( I'll see if there's something we can do to prevent the lockfile format changing in Dependabot updates for now.

[TonyArra]

This also caused a bit of a nightmare for my team, since Travis uses 2.1.4 as well, so we kept our Gemfile.lock on that version. We use one gem hosted on a private repo, and Dependabot was changing the Gemfile.lock automatically in the PRs.

All of our Dependabot PR builds were failing as a result, and we had to add the following line to the before_install step of our travis.yml: - gem install bundler:2.2.27.

We also had to bump the version number at the bottom of the Gemfile.lock, and ensure that our developers' project gemsets are now on 2.2.27. On the plus side, we needed to do all of that anyway to address the security concern; I just didn't expect a Dependabot update to force our hand.

[jurre]

On the plus side, we needed to do all of that anyway to address the security concern; I just didn't expect a Dependabot update to force our hand.

Yeah that's definitely fair.

I think we could patch bundler here to disable the behavior, but I'm a little hesitant if we should. I agree that updating the lockfile format should probably be done outside of dependabot, and us doing so for bundler versions that don't support it is definitely undesirable, but I'm not sure what other side-effects we might introduce with such a patch, and maintaining it might be painful over the long run 🤔

cc @brrygrdn wdyt?

[mobilutz]

I think we could patch bundler here to disable the behavior,

@jurre Wouldn't it be better, to always run bundler with the version from Gemfile.lock?
That way, you would not need to patch anything, and the outcome from a dependabot update would always be the expected one.

I see this as the safest approach and would also then work with ANY bundler version out there.

[jurre]

I think we could patch bundler here to disable the behavior,

@jurre Wouldn't it be better, to always run bundler with the version from Gemfile.lock?
That way, you would not need to patch anything, and the outcome from a dependabot update would always be the expected one.

I see this as the safest approach and would also then work with ANY bundler version out there.

Yep, ideally that would be best, but it's not feasible with how Dependabot is currently implemented, we use bundler both as a library and a CLI, and to manage our own dependencies. It's certainly possible eventually, but we'll need to carve out some dedicated time for it and our teams bandwidth currently doesn't allow for it :(

[mobilutz]

Thanks for the explanation!

[marlabrizel]

I'm glad to see this is actively being worked on! Just wanted to add that I'm also experiencing this same issue with Bundler 2.1.4 - took me several days of debugging to figure out what was up because I was thrown off by the lack of change to BUNDLED WITH. Thanks for looking into it! <3

[abdulapopoola]

Closing as stale