Add experimental support for skipping Ruby install #130
Conversation
This file contains 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
Allows user or another buildpack to set `HEROKU_USE_SYSTEM_RUBY`. This will: - Skip our logic for installing ruby - Trigger a `which ruby` command to run, if it returns non-zero exit the build will not proceed - Trigger a `ruby -v` command to run, if it returns non-zero exit the build will not proceed - Includes a warning message stating that turning this on effectively disables any guarantees of support The main driver is allowing for experimentation of replacing a Ruby binary.
schneems
force-pushed
the
schneems/use-system-ruby
branch
from
7f8db4e
to
5f1c0a4
Compare
|
Can you set: |
## Allow `*` stacks As stacks are going away, we can begin to remove the hard requirement that this buildpack only be run with known stacks. To clarify support I added stack detection warning messages. ## Refactor Ruby and Bundler version logic I've learned a lot since I wrote this original code. I like the way Ed modeled https://github.com/heroku/buildpacks-python/blob/main/src/python_version.rs. This refactor allows us to represent the difference between a build where we are responsible for installing Ruby and one where we're not. We need to be able to bust layer caches based on these versions no matter what so I introduced a `RubyCacheKey` which is not guaranteed to also be an installable `RubyVersion`. The logic in `commons/gemfile_lock.rs` was not great, and it contained structs that seemed like they would better live somewhere else. Functions in `steps/` for bundler and ruby versions (download and install) were very small logically work better if grouped with their associated version logic. ## Updated section variables in main.rs Update variables used for logging runtime duration to match the thing they're measuring. This reads better and helps understand what header is being closed by `done()` calls.
schneems
force-pushed
the
schneems/use-system-ruby
branch
from
3554041
to
6988d42
Compare
schneems
commented
Mar 12, 2023
| user::log_warning( | ||
| "Using System Ruby", | ||
| formatdoc! {" | ||
| Found environment variable {HEROKU_USE_SYSTEM_RUBY}={value:?}. When enabled, you are |
There was a problem hiding this comment.
As we're brainstorming an interface. One thought/question here is debug-ability.
I'm calling ruby -v and erroring if I didn't find a Ruby version on disk. To help debug if that fails I can use https://github.com/schneems/which_problem (perfect use case for that logic TBH). However there's no visibility into where the user was expecting the Ruby version to come from. I think they would want to know:
- Did a user set
HEROKU_USE_SYSTEM_RUBYor was it a buildpack (or host OS)?- We can detect if it came from platform env or in current env
- If it came from buildpack/host-os how can we forward that location to the end user?
- One idea would be to have another env var like
HEROKU_USE_SYSTEM_RUBY_REASONand make it mandatory when not set via platform/user env. Presumably if it's set via another buildpack it would be something likeHEROKU_USE_SYSTEM_RUBY_REASON="core-os-ruby buildpack is installing Ruby" - We could just use the value of
HEROKU_USE_SYSTEM_RUBY, but I bet most buildpacks that choose to set this would just set it to 1 out of laziness. Though maybe not? We could get wild and enforce that it's semi-structured data likebuildpack: <name-of-buildpack>oros: <name-of-os-expected-to-have-ruby>. I'm just trying to think of how we could give users more of a hint of where to look next when things go wrong other then "stuff failed"
- One idea would be to have another env var like
It's useful to think about this now, as it would be a breaking change if we mandate something explicit/different in the future.
|
@jkutner done. Also for completeness sake adding this link regarding stacks going away buildpacks/rfcs#219. I refactored a bunch of logic too. I'm quite happy with the end results. If we end up not keeping this experiment I'll likely want to keep the refactor minus the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Allows user or another buildpack to set
HEROKU_USE_SYSTEM_RUBY. This will:which rubycommand to run, if it returns non-zero exit the build will not proceedruby -vcommand to run, if it returns non-zero exit the build will not proceedThe main driver is allowing for experimentation of replacing a Ruby binary.