Hardcode Gemfile.next for test deploy branch#3
Open
fbuys wants to merge 2 commits intoadd_gemfile_next_supportfrom
Open
Hardcode Gemfile.next for test deploy branch#3fbuys wants to merge 2 commits intoadd_gemfile_next_supportfrom
fbuys wants to merge 2 commits intoadd_gemfile_next_supportfrom
Conversation
As a debugging tool when BUNDLE_GEMFILE does not seem to take effect.
It can also be used to deploy the next rails version without setting
BUNDLE_GEMFILE.
Force BundlerWrapper and ruby.rb to use Gemfile.next/.lock
instead of the BUNDLE_GEMFILE env var or the default Gemfile.
Removes the now-unused current_gemfile/gemfile_path/gemfile_lock_path
helpers from ruby.rb.
Build phase (compile() flow)
- setup_language_pack_environment sets ENV["BUNDLE_GEMFILE"] =
"#{build_path}/Gemfile.next"
→ used by build_bundler (which also hardcodes it via env_vars at line
802, consistent)
- post_bundler → bundler.clean then resets ENV back to nil (this is why
setup_export must hardcode the path, not read from ENV)
Export for subsequent buildpacks (setup_export)
- Hardcodes "#{build_path}/Gemfile.next" directly — immune to
bundler.clean resetting ENV to nil
- Writes export
BUNDLE_GEMFILE="${BUNDLE_GEMFILE:-/tmp/build_.../Gemfile.next}" to the export file
Runtime + release phase (setup_profiled)
- set_env_override "BUNDLE_GEMFILE", "$HOME/Gemfile.next" writes export
BUNDLE_GEMFILE="$HOME/Gemfile.next" to .profile.d/ruby.sh
- Heroku sources .profile.d/ before running release commands and at
every dyno startup, so both the release phase (rake db:migrate etc.)
and running dynos get BUNDLE_GEMFILE=/app/Gemfile.next
Note: self.use? still detects via Gemfile — the test app must include a
Gemfile for buildpack detection to trigger.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As a debugging tool when BUNDLE_GEMFILE does not seem to take effect. It can also be used to deploy the next rails version without setting BUNDLE_GEMFILE.
Force BundlerWrapper and ruby.rb to use Gemfile.next/.lock instead of the BUNDLE_GEMFILE env var or the default Gemfile. Removes the now-unused current_gemfile/gemfile_path/gemfile_lock_path helpers from ruby.rb.
Note: self.use? still detects via Gemfile — the test app must include a Gemfile for buildpack detection to trigger.
Deployment steps:
heroku/rubybuildpack from your app and addhttps://github.com/fastruby/heroku-buildpack-ruby#use_gemfile_next