devcontainers / devcontainers/spec
Consistant automated workspace mounts for Docker Compose
- Dominant language
- No language data
- Stars
- 5.7k
- Forks
- 496
- PR merge metrics
- No merged PRs in 30d
Description
Docker Compose inherently has the ability to bind mount the filesystem, but one challenge that has arisen is inconsistant support in different situations.
* In the VS Code Dev Containers / Remote - Containers extension:
* Bind mounts work as expected in the "open folder" scenario
* However, an automated mount is used in the Clone Repository in Container Volume scenario, resulting in odd behaviors.
* In Codespaces, workspaceMount and workspaceFolder are not yet supported and the same mount point is always used.
Right now there's basically [only one value](https://github.com/microsoft/vscode-remote-release/issues/5388) that works in all three scenarios.
When Docker Compose is not used, an automatic mount point is set that can be overridden with the `workspaceMount` property. This was not originally added to Docker Compose given its native bind mount support. However, given the current situation, I'd propose that this is likely not the right default behavior.
I'd propose change behaviors for consistency:
1. Make `workspaceFolder` optional for Docker Compose like it is for Dockerfile/image.
2. Allow `workspaceFolder` to be used without `workspaceMount` in all scenarios.
* If `workspaceMount` is **not** set, we'd use this value to set the **target** location for the mount.
* Otherwise it just dictates the default workspace folder within the container.
* `workspaceFolder` would keep the existing default of `/workspaces/` in all cases.
3. If `workspaceMount` is **not** set:
* image/Dockerfile: the **source** would be set to the the folder containing `.devcontainer` or `.devcontainer.json` (current state)
* Docker Compose: the **source** would be set to an existing mount point in the docker-compose.yaml file(s) with the same target as `workspaceFolder` if one exists, and otherwise he folder containing `.devcontainer` or `.devcontainer.json`
* The **target** would follow the rules above.
The only reason for the slight variation in the Docker Compose case for workspace mount is backwards compatibility. Samples and templates can then drop the `workspaceFolder` property.
Contributor guide
Assessment
This issue has not been assessed yet.