The Heroku-20-Build Ruby version does not match the Heroku Platform Ruby.
Closed this issue · 3 comments
We are using Heroku-20-build Docker image to simulate the Heroku platform locally in our development environments. We are using the build image as some gems are C extensions and require building. However, the Heroku-20-build has Ruby 2.7.0 and when we do a git push to deploy to the Heroku platform, the platform is expecting Ruby 2.7.2 and rejects the push.
I would have expected the Heroku-20-build Docker image to match the Heroku-20 platform.
@davidhooey Hi! The Heroku stack images act as a base image that contains commonly used OS libraries and tooling, such as OpenSSL, compilers, C library development headers etc. The full list of packages they contain can be seen here:
https://devcenter.heroku.com/articles/stack-packages
Whilst some language toolchains (eg Python and Ruby) are included in the base image for convenience, these are not intended for use by your application, and more to make it easier for various compile-time scripts (that might have a dependency on another language) to just work. For example when using Node.js and npm installing a packaging, it might need to use node-gyp, which requires that Python be available on the system in some form.
Instead, an application's primary language is provided by a buildpack:
https://devcenter.heroku.com/articles/buildpacks
In the case of a Ruby app, that means this buildpack:
https://github.com/heroku/heroku-buildpack-ruby
So in production, your app won't be using the Ruby 2.7.0 from the stack image, but the copy of Ruby installed by the buildpack into your app's slug. The buildpack will also be performing other tasks beyond just providing Ruby -- for example helping to configure Rails.
If you wanted to more closely emulate Heroku builds locally, you would need to use one of the examples from this thread:
#56 (comment)
However, unless you have very specific requirements I would recommend just using the official Docker Hub Ruby images (eg ruby:2.7.2) when developing locally (for reduced complexity/image size), and instead catching the rare dev-prod parity issues via Heroku CI, Review Apps or a staging app.
Awesome, thanks!
You're welcome!