Does not respect workspaceMount, workspaceFolder when using "Open repository in container"

[rickardp]

• VSCode Version: 1.45.1
• Local OS Version: Windows_NT x64 10.0.18362
• Remote OS Version: Alpine 3.11
• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. Specify a custom mount point in devcontainer.json
2. Open repository in container...
3. pwd && ls
4. Observe how the code is in /workspaces/(projectname)

Expected behavior is that the mount point is respected. This is important for my use case since the build system expects the source code to be placed under /src (repurposing an existing Docker-based build system as the dev container).

[Chuxel]

@chrmarti I know we're ignoring workspaceMount since it wouldn't apply in this case, but could we respect workspaceFolder?

[chrmarti]

I think workspaceFolder often depends on workspaceMount taking effect too. Maybe we could parse workspaceMount and try to adapt it for the volume case.

If only workspaceFolder is given we could use it as-is.

[dionysiosarvanitis]

Is there any fix on this. I need workspace to be mounted on /var/www/html. For workaround I use symlink.

[74th]

It would be nice if the workspace was checked out in the workspaceFolder directory (not workspaceMount setting).
In Go development, I'm in trouble because github.com/vscode-debug-specs/go needs to be in /home/vscode/go/src/github.com/vscode-debug-specs/go.

[WasabiFan]

Could someone help me understand this comment from above?

I know we're ignoring workspaceMount since it wouldn't apply in this case, but could we respect workspaceFolder?

As a user, I don't know how the volume hosting the repo is laid out, but when I open a repository in a container I would expect the workspaceMount property to apply. As with others on this thread, my project depends on having the repo in a particular place, and it sounds from the above like the initial conclusion was that this is unsupported and not possible in the future. My guess is that the cloned repo is not at the root of the volume, and that's causing this confusion; is that correct?

Having the file system layout differ depending on how the user launched the container somewhat defeats the purpose of a consistent dev environment for me, and it means I can't easily implement a workaround in my Docker image.

As an additional piece, the fact that these properties are silently ignored is rather confusing; if I didn't know to do an issues search on this repo I would be assuming it was a bug or misconfiguration.

cc @Chuxel

[Chuxel]

@WasabiFan workspaceMount dictates where the source code comes from in addition to where it goes to in the container. In this case the source code is in the root of a volume, so the "src" doesn't apply.

[rickardp]

Any ideas on how to solve this?

It becomes quite important for e.g. typescript development on Windows, since "npm install" and bind mounts is a painful experience due to how Docker for Windows is designed.

Additionally, this is needed to work with e.g. shell scripts since Docker for Windows seems to not handle Unix permissions well (again, due to poor design choices by Docker, not the fault of this extension).

I think respecting workspaceFolder sounds like a reasonable solution, at least from a user point of view.

[Chuxel]

@rickardp This is a feature request though I noticed it wasn't tagged.

If you need to use another path, a simple workaround is to use a symbolic link. For /var/www/html, you can add "postCreateCommand": "sudo mkdir -p /var/www && sudo ln -s $(pwd) /var/www/html" do devcontainer.json which will cause html to point to the repository root.

Since $(pwd) is the root of your repo, you can use $(pwd)/sub/folder/goes/here to link a repo sub-folder instead.

[rickardp]

@Chuxel Thanks. In my particular case this does not work unfortunately. The "workaround" is to run Docker off a Linux VM at the moment, quirky but works well once set up.

The expectation though was that workspaceFolder was respected, and although I get that you want to treat it as a new feature, I would argue that the logical conclusion from users is that it would work the same way regardless how you clone the repo.

[chrmarti]

Same cause as #5388.

[jrhemstad]

I'd really like to see this addressed as it is blocking us from being able to provide a single click link to launch into our devcontainer as described here: https://code.visualstudio.com/docs/devcontainers/create-dev-container#_add-an-open-in-dev-container-badge

I think this is a killer feature of projects that use devcontainers and it is really a bummer to not be able to take advantage of it.