Vscode-remote-release: Allow for use of variables in devcontainer.json

[ahayzen]

It would be useful if variables ( https://code.visualstudio.com/docs/editor/variables-reference ) could be used in devcontainers.json, at the moment adding variables to, eg, runArgs fails.

A use case for this might be trying to mount data in the project folder to a specific location eg --volume=${workspaceFolder}/mydb.sqlite:/srv/webapp/mydb.sqlite.

It is possible to workaround this at the moment by using absolute paths but this may allow for more dynamic definitions.

Note environment variable do work.

[egamma]

Variables are supported in runArgs see https://github.com/microsoft/vscode-remote-release/issues/142#issuecomment-489417210.

@Chuxel I haven't found this documented?

[Chuxel]

@egamma You are right, looks like it isn't. I added it as another sample that uses it to bind mount your home directory into the container. Mounting additional volumes is another topic we support but is in tips and tricks, but is more common. Two birds with one stone.

I've got it queued up to go with the advanced topics when that goes.

[ahayzen]

Thanks for adding docs !

Yes I found that env variables work in the runArgs but I have found that the "predefined variables" that don't seem to work, eg using ${workspaceFolder} does not work.

Eg a runArgs such as the following

"runArgs": [
    "--volume=${workspaceFolder}:/test:ro"
]

Fails like this

Run: docker run -a STDOUT -a STDERR -v /home/andrew/Projects/vscode-qt-test:/workspaces/vscode-qt-test -v /home/andrew/.gitconfig:/home/developer/.gitconfig -l vsch.quality=insider -l vsch.local.folder=/home/andrew/Projects/vscode-qt-test -l vsch.remote.devPort=9753 --volume=${workspaceFolder}:/test:ro vsc-vscode-qt-test-4a8273a754e9fdaf0918bfb644b6eec3 /bin/sh -c echo Container started ;  while sleep 1; do :; done
docker: Error response from daemon: create ${workspaceFolder}: "${workspaceFolder}" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.
See 'docker run --help'.
Failed: Starting the development container
Command failed: docker run -a STDOUT -a STDERR -v /home/andrew/Projects/vscode-qt-test:/workspaces/vscode-qt-test -v /home/andrew/.gitconfig:/home/developer/.gitconfig -l vsch.quality=insider -l vsch.local.folder=/home/andrew/Projects/vscode-qt-test -l vsch.remote.devPort=9753 --volume=${workspaceFolder}:/test:ro vsc-vscode-qt-test-4a8273a754e9fdaf0918bfb644b6eec3 /bin/sh -c echo Container started ;  while sleep 1; do :; done

I was expecting this to mount the workspace folder from the host into the container at the specified mount point.

[Chuxel]

@ahayzen Ah! Got it - yes, that is a feature request, you are right. Removed docs and added the feature-request label given that.

[ulrichSchreiner]

hi,

it would be great to support the variables not only in runArgs. i tried to do this
~
"workspaceFolder": "${workspaceFolder}",
~
and it also did not work. the remote workspace is /.

i want the path of my sources to be equal to the real path. when you're doing go (or other compiler based languages i guess) the path to the sources is part of a stacktrace. i can compile the sources in the container or outside and depending on where i compiled, the source-path's are different.

you also cannot debug a binary which was not compiled in the dev-container when the source path's are wrong. everything is easier if the dev-container feels like your local machine.

so it would be great to mount and open the same path as it is locally.

[Ciantic]

Error response from daemon: invalid mount config for type "bind": invalid mount path: '${workspaceFolder}/keymap' mount path must be absolute.

With devcontainer.json

{
    "workspaceMount": "src=${workspaceFolder}/keymap,dst=/qmk_firmware/keyboards/ergodox_ez/keymaps/ciantic,type=bind,consistency=cached",
    "workspaceFolder": "/qmk_firmware",
}

[KevinGuancheDarias]

@Ciantic I had this issue too, maybe you are using Docker Toolbox in a Windows machine, when passing the path to the docker command, is doing something like c:/Users/foo/bar which to Linux is a relative path

[Chuxel]

@KevinGuancheDarias @Ciantic ${localWorkspaceFolder} is the local path, but if you are connecting to something remote, be aware that this will be the local filesystem's view of the folder, not the container's (this was added in #442). The name isn't workspaceFolder because the name is ambiguous - it can be either the container or local one.

@chrmarti Should we consider closing this to avoid future confusion? Even though this mentions other variables, I've never actually seen anyone mention anything other thank workspaceFolder.

[chrmarti]

I agree, we support ${env:XYZ} and ${localWorkspaceFolder}. (${localEnv:XYZ} and ${containerEnv} in Insiders.)

Let's track additional variables in new tasks. Closing this one.