[Bundler] Support multiple lockfiles - for example dual-booting

[davidwessman]

Background

Some applications have multiple gemfiles and lockfiles, it would be great if Dependabot could support updating them more seamlessly. I have seen two separate discussions in issues here on Dependabot:

• Support multiple gemfiles #375 Discussing having one Gemfile for testing a gem against each supported Rails version.

  • ActiveAdmin has multiple Gemfile and Gemfile.lock in separate folders, for example ./gemfiles/rails_52/Gemfile, ./gemfiles/rails_52/Gemfile.lock.
  • They fixed their situation by configuring dependabot to update each folder separately: dependabot.yml.
  • Multiple Gemfiles can be updated separately and therefore the solution with many folders work.
  • Good: They will receive one PR for each update to Rails.
  • Bad, but works: They will receive the same PR for each gemfile if a shared dependency is updated.

• Support multiple lock files for Bundler #2106 Discusses multiple Gemfiles for dual-booting a Rails application, see more information from fastruby.io or Shopify's bootboot.

  • An example dual-booted with fastruby's setup is https://github.com/davidwessman/synka.
  • One Gemfile, one Gemfile.next which is just a symlink to the main one, then two separate lockfiles Gemfile.lock and Gemfile.next.lock (For bootboot the files are called Gemfile_next and Gemfile_next.lock).
  • Some of the listed dependencies and versions are only used for Gemfile.lock and some for Gemfile.next.lock, but as many as possible are shared.
  • Bad: When an update is done in the Gemfile with a specified requirement, the Gemfile.next.lock gets out of sync with its Gemfile and the application is no longer deployable in both versions.

My solution to the second situation have been running a special Github Action Workflow everytime there is a PR with changes to Gemfile.lock and just run BUNDLE_GEMFILE=Gemfile.next bundle update --minor --conservative and commit the change. But this no longer works for PRs triggered by Dependabot since the read-only update on the 1st of March, blog post.

Example

A Gemfile with a symlinked file called Gemfile.next.

Gemfile and Gemfile.next

def next?
  File.basename(__FILE__) == "Gemfile.next"
end

source "https://rubygems.org"

if next?
  gem "business", "~> 6.0"
else
  gem "business", "~> 5.0"
end

gem "shared", "~> 2.1"

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    business (5.0.1)
    shared (2.1.3)

PLATFORMS
  ruby

DEPENDENCIES
  business (~> 5.0 )
  shared ( ~> 2.1)

RUBY VERSION
   ruby 2.7.2p137

BUNDLED WITH
   2.2.7

Gemfile.next.lock

GEM
  remote: https://rubygems.org/
  specs:
    business (6.0.3)
    shared (2.1.3)

PLATFORMS
  ruby

DEPENDENCIES
  business (~> 6.0 )
  shared ( ~> 2.1)

RUBY VERSION
   ruby 2.7.2p137

BUNDLED WITH
   2.2.7

Update cases

• shared: Update to the maximum version working for both lockfiles
  • Always update both lockfiles in the same PR when a shared dependency is updated.
• business: Update Gemfile or Gemfile.next separately, can be separate PRs.

Required changes

• Support parsing gemfiles with other names: Gemfile.next + Gemfile.next.lock or Gemfile_next + Gemfile_next.lock
• Allow a dependency to have multiple available versions, connected to a Gemfile and a lockfile.
• ???

I would be interesting in helping out with a PR, but I think I need some guidance to make it work - I started out with #3262 but decided to close it and start this issue instead.

[feelepxyz]

@davidwessman great feedback, we actually want this for a project at github but having a hard time prioritising it atm.

We've set up a sample workflow that works around the new read-only GITHUB_TOKEN on dependabot PRs here: https://github.com/dependabot/dependabot-actions-workflow/tree/main/.github/workflows

[deivid-rodriguez]

Yeah, this would be an awesome feature. Our current setup in activeadmin works but it's way too verbose, since we get one separate PR for each [gemfile, lockfile] couple when updating shared dependencies.

It'd be nice if we could move back to using a "common gemfile" through eval_gemfile, and that dependabot automatically detected that a dependency upgrade happened inside the common Gemfile, and automatically upgraded all gemfiles/lockfiles using it.

[kyleboe]

Might also be worth considering Shopify's dual boot tool and their naming convention of Gemfile_next.lock.