docker
Provide the ability to mount the source code volume into the docker-compose service containers at custom mount points
Tell us about your request When a git repo is cloned it is into a volume and then the .docker/docker-compose.yaml file in that volume is read and executed - but the original volume containing the source code isn't available to the docker-compose service containers. It would be great to have the ability to say, in the docker-compose.yaml file, something like "In service A mount the source code volume to this path" and "In service B mount the source code to this other path". I'm sure this would be easy using named volumes except the source code volume has a dynamic name so some sort of pre-defined alias would be needed.
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? When developing using docker with the source code on the local filesystem you can use mounts to mount the source code into the docker containers but this is slow because of the file sync process needed for Mac and Windows. By using Dev Environments and directly cloning a git repo into a volume you avoid this but the source code volume still needs to be available to the docker-compose services or nothing works.
This is blocking me from using dev environments. I built a custom dev environment system that I've been using professionally for half a year. In my system all dev-containers are ephemeral and connect to a single docker volume. The base images have docker-in-docker and dockerized apps (bins that look like apps to the terminal but they just exec docker functions), with scripts that force the dockerized apps to only run within the dev volume. The base image also sources scripts that automate git cloning projects into the dev volume in a structured way (/dev-volume/github-org/repo-name).
To summarize: I might use docker dev-environments if I could specify a volume to always be attached. I would defiantly use dev-environments if the "EXISTING DEV ENVIRONMENTS" page was more user friendly, like the ability to save presets of favorite base images, ability to attach volumes and networks when launching the preset, ability to name the spawned dev-container so that scripts within my base images can check if a dev environment is already running and exec a process instead of running a new container.
... also if anyone is listening, pretty please add the "Open in VS Code" option to every container, not just dev-containers. In my system above I need to open VSCode and then "attach to running container", a slight annoyance as the page opens a new window and I usually want to close the first one.
Hello @far-blue and @higginsrob
Thanks for your feedbacks, I'll open some tickets in our internal tracker to let our PM know about your usages. Also @higginsrob for your "Open In VS Code" option, I think the best option will be to open an issue in the public Roadmap repository
