Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consistant automated workspace mounts for Docker Compose #106

Open
Chuxel opened this issue Sep 29, 2022 · 0 comments
Open

Consistant automated workspace mounts for Docker Compose #106

Chuxel opened this issue Sep 29, 2022 · 0 comments
Labels
proposal Still under discussion, collecting feedback

Comments

@Chuxel
Copy link
Member

Chuxel commented Sep 29, 2022

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:

  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/<sub-folder-name-here> 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.

@Chuxel Chuxel added the proposal Still under discussion, collecting feedback label Sep 29, 2022
adamiak added a commit to l2beat/starkex-explorer that referenced this issue Jun 18, 2023
See devcontainers/spec#106 - "there's basically only one value that works in all three scenarios."
github-merge-queue bot pushed a commit to l2beat/starkex-explorer that referenced this issue Jun 23, 2023
See devcontainers/spec#106 - "there's basically only one value that works in all three scenarios."
github-merge-queue bot pushed a commit to l2beat/starkex-explorer that referenced this issue Jun 23, 2023
See devcontainers/spec#106 - "there's basically only one value that works in all three scenarios."
adamiak added a commit to l2beat/protocolbeat that referenced this issue Nov 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
proposal Still under discussion, collecting feedback
Projects
None yet
Development

No branches or pull requests

1 participant