You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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:
Make workspaceFolder optional for Docker Compose like it is for Dockerfile/image.
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/<sub-folder-name-here> in all cases.
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.
The text was updated successfully, but these errors were encountered:
Docker Compose inherently has the ability to bind mount the filesystem, but one challenge that has arisen is inconsistant support in different situations.
Right now there's basically only one value 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:
workspaceFolder
optional for Docker Compose like it is for Dockerfile/image.workspaceFolder
to be used withoutworkspaceMount
in all scenarios.workspaceMount
is not set, we'd use this value to set the target location for the mount.workspaceFolder
would keep the existing default of/workspaces/<sub-folder-name-here>
in all cases.workspaceMount
is not set:.devcontainer
or.devcontainer.json
(current state)workspaceFolder
if one exists, and otherwise he folder containing.devcontainer
or.devcontainer.json
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.The text was updated successfully, but these errors were encountered: