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

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

Open
rickardp opened this issue May 22, 2020 · 11 comments
Assignees
Labels
containers Issue in vscode-remote containers feature-request Request for new features or functionality plan-review PM-highlighted item determined to be P1 or P2 volume Dev Container mounting a Docker volume

Comments

@rickardp
Copy link

  • 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
Copy link
Member

Chuxel commented Jun 9, 2020

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

@Chuxel Chuxel added the containers Issue in vscode-remote containers label Jun 9, 2020
@chrmarti
Copy link
Contributor

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
Copy link

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

@74th
Copy link

74th commented Jul 18, 2020

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
Copy link

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
Copy link
Member

Chuxel commented Sep 12, 2020

@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
Copy link
Author

rickardp commented Sep 12, 2020

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 Chuxel added the feature-request Request for new features or functionality label Sep 12, 2020
@Chuxel
Copy link
Member

Chuxel commented Sep 12, 2020

@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
Copy link
Author

@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
Copy link
Contributor

Same cause as #5388.

@jrhemstad
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
containers Issue in vscode-remote containers feature-request Request for new features or functionality plan-review PM-highlighted item determined to be P1 or P2 volume Dev Container mounting a Docker volume
Projects
None yet
Development

No branches or pull requests

9 participants