andrewn617
commented
2 months ago Hi @patriciomacadden Thanks for the PR! This is actually a feature I have had in mind as well and played with a bit but didn't come up with an implementation I liked, and I have been meaning to come back to it. At first glance this looks good. I want to do some testing with it on my end but I probably won't have time to get to that until sometime next week. I will get back to you once I have had time to take a closer look =)
patriciomacadden
Hello!
I've been using docker and docker compose for years to run my rails apps in development. The way I used docker + docker compose was to run a single process and remove the container after it's done (eg
docker compose run --rm ..., or justdocker compose upand them removing the container, etc). And when you're adding gems, trying things out, etc. it's super useful to have a volume for the installed gems so you can rundocker compose run web bundleand have the new gems available rather than having to rebuild the image over and over.Devcontainers approach, ie developing inside of the container, is really interesting but there's something that slows down the whole thing of bringing the container up and that is to install gems every time (if you remove containers after a period of time obviously, if you don't you're fine).
This feature could've been in its own repo but I thought this is a good place to be as people like me might find useful.
This feature just creates a volume that gets mounted in
/bundleand adds theBUNDLE_PATHenv var to/vendor/bundle. This way you might remove the container and when you bring it up again it will use the gems you already have installed, making the whole process faster. The reason why there's a postCreateCommand is that the mounted volume needs to be owned by the vscode user, as the devcontainer doesn't run as root. I couldn't find a different way editing the compose.yaml or devcontainer.json. Apologies if there's another way!