[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.

[github-actions]

👋 This issue has been marked as stale because it has been open for 2 years with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the Keep label to hold stale off permanently, or do nothing. If you do nothing, this issue will be closed eventually by the stale bot. Please see CONTRIBUTING.md for more policy details.