-
Notifications
You must be signed in to change notification settings - Fork 787
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App fails to start on Heroku-22 stack due to lack of erb executable #101
Comments
@habovh Hi! Thank you for the report - I agree this isn't ideal at present. This repo currently has no CI (filed #102) :-( I've started a discussion internally as to how we should proceed. I wasn't aware this buildpack used Ruby for the custom templating feature. It seems our options are:
|
The ERB templating feature of this buildpack requires that the `erb` command (part of Ruby) be available at runtime, in order that the nginx config templates can be rendered into a valid nginx config. On Heroku-22 the stack image no longer includes a system Ruby installation, so in order for this buildpack to continue to work, a Ruby install must be vendored by this buildpack. If an app already uses the Ruby buildpack, and that buildpack is ordered prior to the nginx buildpack, then this buildpack will skip the Ruby vendoring step to save installing a redundant copy of Ruby. Fixes #101. GUS-W-11321729.
The ERB templating feature of this buildpack requires that the `erb` command (part of Ruby) be available at runtime, in order that the nginx config templates can be rendered into a valid nginx config. On Heroku-22 the stack image no longer includes a system Ruby installation, so in order for this buildpack to continue to work, a Ruby install must be vendored by this buildpack. If an app already uses the Ruby buildpack, and that buildpack is ordered prior to the nginx buildpack, then this buildpack will skip the Ruby vendoring step to save installing a redundant copy of Ruby. Fixes #101. GUS-W-11321729.
@edmorley thanks for the quick reply! The buildpack would indeed benefit from CI that's for sure 😅 I think that the best short-term approach is the option 1 —just as you planned on #103. Slug size will increase in our case by about 20MB, give or take. I guess that's acceptable for the time being, as long as the slug size is not already nearing the max slug size and the vendoring does not require users to put placeholder Gemfile and Gemfile.lock files in their app. Not having used Ruby in quite some time, it was pretty much a trial-and-error approach to get these two files right to satisfy the ruby buildpack validation. In the longer run, I could see either option 2 or 3 working fine. In our case we're mainly using the templating feature of ERB to leverage environment variables and include their values in the generated config. Now, I know ERB can do much more than that so it might be wise to check actual use before going on another templating engine. Regarding option 3 specifically, I have no experience with ports and don't know of any, but if such a port exists and meets the standard it might be a nice lightweight and zero-effort update for users to switch to the new heroku-22 stacks. |
The ERB templating feature of this buildpack requires that the `erb` command (part of Ruby) be available at runtime, in order that the nginx config templates can be rendered into a valid nginx config. On Heroku-22 the stack image no longer includes a system Ruby installation, so in order for this buildpack to continue to work, a Ruby install must be vendored by this buildpack. If an app already uses the Ruby buildpack, and that buildpack is ordered prior to the nginx buildpack, then this buildpack will skip the Ruby vendoring step to save installing a redundant copy of Ruby. Fixes #101. GUS-W-11321729.
@habovh The latest published version of this buildpack will now work on Heroku-22 without the Ruby buildpack having been manually added to the app's buildpacks list. An empty |
@edmorley nice! Seems to work as expected on our end as well. Thanks for the quick reaction time! I'll be monitoring the buildpack in case you decide to go with another solution down the road. |
We've been using this buildpack for a while now, and would like to transition from the Heroku-20 stack to the new Heroku-22 stack.
As per the heroku-22 stack documentation/release notes, Ruby is no longer included on the system level.
The Nginx buildpack uses
erb
to parse the Nginx configuration file, so it needs at least some parts of Ruby:heroku-buildpack-nginx/bin/start-nginx
Lines 7 to 8 in 7b37d07
At first I thought we could use the
heroku/ruby
buildpack to make up for the now-missingerb
binary. However, according to the documentation, since our app doesn't actually use Ruby we also don't have a Gemfile, and the build fails because of the failed check from the Ruby buildpack.Adding empty Gemfile & Gemfile.lock files in our repo seems like quite a hack to include Ruby buildpack, only to be able to use the Nginx buildpack. It also feels quite odd to add such a large dependency ourselves, increasing slug size as well and forcing us to also update the ruby version whenever it reaches its own EOL. For reference, our slug size when using nginx-buildpack only is 191.4M. When adding the ruby buildpack, we're at 213.9M.
Now I know our current heroku-20 stack is nowhere near its end of life (scheduled April 2025), but I'd still like to be able to do a clean update to heroku-22 when able.
Could we somehow include
erb
in the nginx buildpack to avoid having to installing another buildpack just for the configuration parsing? Would it make sense to create a buildpack that would only includeerb
to use along nginx-buildpack, if that's even doable? Is the Ruby buildpack the "correct" approach here, even for non-ruby apps, with an empty Gemfile to please the validator?Here's an excerpt from the app logs when starting on heroku-22 with only the Nginx buildpack.
For people needing to get nginx buildpack work on heroku-22 asap, you can use the following Gemfile and Gemfile.lock along with the Ruby buildpack:
Gemfile:
Gemfile.lock:
The text was updated successfully, but these errors were encountered: