A buildpack that gives your Ruby app the ability to run with multiple Gemfiles. It works alongside Heroku's ruby buildpack.
You may want to use this during Rails upgrades to run two Rails versions simultaneously in the same Heroku environment. For example, you could have some of your dynos running the current Rails version, and the rest of your dynos running the next Rails version.
- Capable of running 2 different gemfiles
Gemfile
andGemfile.next
from one Heroku slug - Configurable to run tests against both gemfiles when using Heroku CI parallel
- Allows you to run two Rails versions in production
- Uses an env var to specify which dynos you want to use
Gemfile.next
-
WARNING You should not assume my copy of this repo will continue to exist, or be stable, or secure for your application in the future. Fork this repo so you have a copy under your control under your own GitHub account.
-
Add a buildpack after your existing heroku/ruby buildpack. For
app.json
see below. ReplaceYOUR-GITHUB-ACCOUNT
with your GitHub user/org name.
"buildpacks": [
{ "url": "heroku/ruby" },
{ "url": "https://github.com/YOUR-GITHUB-ACCOUNT/heroku-buildpack-multiple-gemfiles" }
]
If you want Heroku CI support, you'll also need to include this buildpack in the environments > test > buildpacks
array in app.json
.
-
Create
Gemfile.next
with its dependencies in your project root. This is the same directory as your existingGemfile
. -
Generate
Gemfile.next.lock
by running:
BUNDLE_GEMFILE=Gemfile.next bundle install
-
Commit
Gemfile.next
andGemfile.next.lock
to your git repository. -
For Heroku CI support, set the
DEPENDENCIES_NEXT_CI_NODES
environment variable (in theenvironments > test > env
object inapp.json
) to a comma-separated string of node indexes you want to useGemfile.next
.
For example, if you have 4 CI nodes in total, and you want the first 2 nodes to use Gemfile
(the default), and the last 2 nodes to use Gemfile.next
, set the following:
"DEPENDENCIES_NEXT_CI_NODES": "2,3"
(CI nodes are zero-indexed.)
- To specify which dynos use
Gemfile.next
, set theDEPENDENCIES_NEXT_DYNOS
environment variable to a comma-separated string of dyno names with glob/wildcard (*
) support.
DEPENDENCIES_NEXT_DYNOS=*
would cause all dynos to useGemfile.next
.DEPENDENCIES_NEXT_DYNOS=worker.1,scheduler.*,web.*,run.*
would causeworker.1
and allscheduler
,web
and one-offrun
dynos to useGemfile.next
. All other dynos would useGemfile
.DEPENDENCIES_NEXT_DYNOS=web.5,web.6,worker.3
would cause dynosweb.5
,web.6
, andworker.3
to useGemfile.next
. All other dynos would useGemfile
.
When Heroku builds your app, these additional steps are performed by this buildpack:
-
Installs gems specified in
Gemfile.next.lock
into your slug. -
Writes a shell script in your dyno's
.profile.d/
directory which sets environment variables on startupBUNDLE_GEMFILE=Gemfile.next
andDEPENDENCIES_NEXT=true
for the dynos you specify in theDEPENDENCIES_NEXT_DYNOS
environment variable (orDEPENDENCIES_NEXT_CI_NODES
for Heroku CI).
If you need to rollback to using Gemfile
on a dyno instead of Gemfile.next
, change the value of DEPENDENCIES_NEXT_DYNOS
. All dynos will restart and only those dynos specified in DEPENDENCIES_NEXT_DYNOS
will use Gemfile.next
. All other dynos will use Gemfile
. If you want no dynos to use Gemfile.next
, you can delete the DEPENDENCIES_NEXT_DYNOS
environment variable.
heroku run --app YOUR_HEROKU_APP_NAME -- BUNDLE_GEMFILE=Gemfile.next bundle exec rails console