I'm installing ruby with rbenv so that if the dev.to repo ever updates the .ruby-version file this image will use the correct version of ruby.
The reason I have to add .rbenv/bin and .rbenv/shim to the $PATH is that the rbenv-install will fail with an exit code > 0 if those do not exist in the $PATH. It looks funny to me that I have to modify the $PATH then install rbenv-installer, but this seems to be a quirk of rbenv-doctor which is run after the installation.
I'm hoping to clean up the Dockerfile as I write out this series of posts.
I like the forward thinking of not needing to modify an upstream source provider content, esp. due to a minor increment.
But on the other hand I though if any of the app files change (ie .ruby-version)
shouldn't the image be rebuilt and the dependent containers restarted?
The phrase "There are no solutions, only trade-offs" comes to mind.
To your point I think there is a better solution than what I've provided in this article. I should be using a multistage build. If I were building dev.to on a container for production I'd probably have a build pipeline for each commit that would do something like:
build a ruby image based off .ruby-version file
build a dependency image from the ruby image off the gemfile/yarnfile
build an image with compiled assets
add in the app code
The only time all the build steps get run is when the ruby-version is updated, otherwise the build uses the cache (assuming docker is able to cache i.e. the build is not running in ephemeral infrastructure). In the normal case where the app code is changing but the dependencies are not only the last step is executed which should be relatively quick.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Two points here
.ruby-version
file this image will use the correct version of ruby..rbenv/bin
and.rbenv/shim
to the $PATH is that the rbenv-install will fail with an exit code > 0 if those do not exist in the $PATH. It looks funny to me that I have to modify the $PATH then install rbenv-installer, but this seems to be a quirk of rbenv-doctor which is run after the installation.I'm hoping to clean up the Dockerfile as I write out this series of posts.
Interesting, I am conflicted.
I like the forward thinking of not needing to modify an upstream source provider content, esp. due to a minor increment.
But on the other hand I though if any of the app files change (ie .ruby-version)
shouldn't the image be rebuilt and the dependent containers restarted?
The phrase "There are no solutions, only trade-offs" comes to mind.
To your point I think there is a better solution than what I've provided in this article. I should be using a multistage build. If I were building dev.to on a container for production I'd probably have a build pipeline for each commit that would do something like:
The only time all the build steps get run is when the ruby-version is updated, otherwise the build uses the cache (assuming docker is able to cache i.e. the build is not running in ephemeral infrastructure). In the normal case where the app code is changing but the dependencies are not only the last step is executed which should be relatively quick.