Support for adding unique ID into volume mount names

[Chuxel]

This proposal is an enhancement idea to the current dev container features proposal.

---

This spec proposal is a port of the proposed solution to microsoft/vscode-remote-release#5679 and relates to #2 (comment).

For both Dev Container Features (#61) and normal devcontainer.json scenarios, it is sometimes necessary to have a unique identifier generated that can be referenced in different places.

The most critical example of this is named volumes. When you have multiple dev containers running in the same environment (e.g. locally), the docker-in-docker feature needs to be able to create unique volume names for each to store docker data. Any feature that references a mount point will face the same challenge.

The proposed solution is to introduce a variable like ${devcontainerId} that is a unique identifier for the resulting container. The format of the identifier does not matter as much as the fact it can be broadly used. So generally it should be alpha numeric. Features can then reference this identifier where appropriate (like in mounts).

@alexdima @chrmarti @jkeech @edgonmsft - This has been the most consistent ask from early adopters of dev container features to date. So I think we'll want to cover it in the spec.

[stuartleeks]

Is there any consensus on how the devcontainerId value would be generated?

My initial thought when thinking about this a while back was to use the name from devcontainer.json. The downside is that changing the name would break the volume links, which isn't ideal. Especially as I often start working with a dev container for a while before noticing that I haven't put something meaningful in the name value so end up changing it later to something to help identify the project.

Another idea is to add an id property to devcontainer.json and have the CLI/extension populate it with a new randomly generated value if it doesn't exist. This could then be the value used for devcontainerId and users could still rename the dev container without breaking the volume links in features.

[stuartleeks]

An alternative to generating the id and modifying a user's devcontainer.json would be to use id if it exists and name (or a derivative of it) as a fallback. In this case, it might help steer into the pit of success if the extension auto-generated a random id value when a user adds a devcontainer.json via the "Remote-Containers: Add Development Container Configuration Files..." command?

[chrmarti]

I would use a similar approach to how we name images which uses vsc-${workspaceFolderBasename}-${workspaceFolderHash}.

To also support the repository in volume case in Remote-Containers (and possibly other cases) we need to base the hash on the id labels we use to identify the dev container (the id label includes the workspace folder path in the local case). It would be nice to have a human-readable part, but that might not be easy to derive in all cases.

So my proposal is to use a sha-256 hash of the id labels (there can be multiple such labels and they all need to match to identify the dev container).

[stuartleeks]

When I look at a dev container running locally, I have the following labels:

  "com.visualstudio.code.devcontainers.id": "python-3",
  "com.visualstudio.code.devcontainers.release": "v0.231.6",
  "com.visualstudio.code.devcontainers.source": "https://github.com/microsoft/vscode-dev-containers/",
  "com.visualstudio.code.devcontainers.timestamp": "Wed, 13 Apr 2022 00:28:49 GMT",
  "com.visualstudio.code.devcontainers.variant": "3.10-bullseye",
  "desktop.docker.io/wsl-distro": "Ubuntu",
  "devcontainer.local_folder": "\\\\wsl.localhost\\Ubuntu\\home\\stuart\\source\\my-project",
  "version": "0.203.5"

Which of these do you suggest are included in the hash?

My goal is to have an ID that is scoped to an individual dev container and that doesn't change across dev container renames (i.e. changing name in devcontainer.json) or VS Code release versions etc

[chrmarti]

In this case only "devcontainer.local_folder": "\\\\wsl.localhost\\Ubuntu\\home\\stuart\\source\\my-project" would go into the hash.

A container created from a repository cloned to a volume has different id labels, e.g.:

"vsch.local.repository": "https://github.com/chrmarti/vscode-regex.git/tree/main",
"vsch.local.repository.folder": "vscode-regex",
"vsch.local.repository.volume": "vscode-regex-main-29a8aa263ac65c28ae2f5568b6fd157f"

In the code these labels are passed around as idLabels IIRC.

[Chuxel]

@chrmarti I assume this would also work if a volume was used for the source code in the Remote - Containers case, correct?

[chrmarti]

@Chuxel Yes, the variations I'm aware of are:

Local folder:

"devcontainer.local_folder": "\\\\wsl.localhost\\Ubuntu\\home\\stuart\\source\\my-project"

"Clone Repository in Container Volume":

"vsch.local.repository": "https://github.com/chrmarti/vscode-regex.git/tree/main",
"vsch.local.repository.folder": "vscode-regex",
"vsch.local.repository.volume": "vscode-regex-main-29a8aa263ac65c28ae2f5568b6fd157f"

When inspecting a volume:

"vsch.local.volume": "myvolume"

Codespaces (here the unique id might not be relevant at the moment):

"Type": "codespaces"

(Using a fixed id label is fine when that uniquely identifies the dev container among other containers on the same Docker host.)

The Dev Container CLI only has the local folder case built-in, in all other cases we pass id labels to the CLI as command line options (--id-label).