Rails 8.1.something Kamal build assumes that vendor/ exists in the repository and that it contains vendored gems. This is incompatible with my Docker containers, where I assumed I could put all gems in vendor/ as an alternative to something that was causing me grief when I was flailing around learning Docker.
This gets me thinking about .gitignore, which I currently have to set up just after creating a Rails app, because all the caches and gems are under the current directory. If gems and caches were installed somewhere outside the project tree, we could save some nuisance with .gitignore.
I think I landed on putting gems in vendor/ because when I changed Ruby version, or maybe even just bundle update, I would run into permission issues. The old "created volumes are created as root" problem.
I already still have issues when changing the Ruby version of a container. Maybe that's even an artifact of how I do this. Because the cache and vendor/ directories survive container rebuilds, I have the wrong versions. And ??? what's the issue??? I can't remember now why I have to blow away the vendor and cache directories when I rebuild the container with a different version.
Also (at the risk of making this issue too big), the credential files shouldn't be copied into the container. We want to be able to ship gems from inside the container, but that requires RubyGems credentials. Also, to ssh anywhere we want to get at the host's keys/key agent.
Rails 8.1.something Kamal build assumes that
vendor/exists in the repository and that it contains vendored gems. This is incompatible with my Docker containers, where I assumed I could put all gems invendor/as an alternative to something that was causing me grief when I was flailing around learning Docker.This gets me thinking about
.gitignore, which I currently have to set up just after creating a Rails app, because all the caches and gems are under the current directory. If gems and caches were installed somewhere outside the project tree, we could save some nuisance with.gitignore.I think I landed on putting gems in
vendor/because when I changed Ruby version, or maybe even justbundle update, I would run into permission issues. The old "created volumes are created as root" problem.I already still have issues when changing the Ruby version of a container. Maybe that's even an artifact of how I do this. Because the cache and
vendor/directories survive container rebuilds, I have the wrong versions. And ??? what's the issue??? I can't remember now why I have to blow away thevendorand cache directories when I rebuild the container with a different version.Also (at the risk of making this issue too big), the credential files shouldn't be copied into the container. We want to be able to ship gems from inside the container, but that requires RubyGems credentials. Also, to
sshanywhere we want to get at the host's keys/key agent.