[silvamerica]

Thanks!

We looked at the approach of adding a Gemfile.tip, however we like the data volume approach because it doesn't require any changes to the Dockerfile and it is more like what our developers are familiar with. A Gemfile.tip can become basically another Gemfile eventually, so separating the bundle step from the build step (in Development) gives us more flexibility as well as keeping things more in line with what our developers expect to do.

What does setting the modified time of all files do?

[buss]

I'm a bit confused by your bundler-cache. It seems you must be running `bundle install` at runtime, because you can't mount that volume during build. Am I misunderstanding?

[silvamerica]

That's correct. You build the image and then run (from inside a container) bundle install. This mapped well with our current flow, where you need to run bundle install after fetching new code anyway. This way, when you fetch new code, you don't need to rebuild the image and launch new containers, unless something changes in the Dockerfile or the docker-compose.yml file. That now happens fairly rarely, and, when it does, it's a pretty quick process.

You don't have to run it at runtime, however, as the data volume for a container sticks around until the container has been deleted. If you don't delete the bundler-cache container, your bundler cache sticks around. If you want to clear the cache, just remove the container.

[nleach]

To add to silvamerica's comment, this process is specific to running containers in development. When building images for deployment the dependencies are installed as a RUN step in the Dockerfile.