Overlay .devcontainer

[bhack]

We need to find a way to overlay .devcontainer.
Suppose that user are switch commented lines on default setting to enable GPU as in microsoft/vscode-dev-containers#381.
I still want to distribute updates but if users are editing the same file that I am distributing it will be hard to get updates. So I suppose that user overrides need to be placed in a separate file.
Just to explore some solutions we could get some ideas from https://github.com/kubernetes-sigs/kustomize#2-create-variants-using-overlays.

[Chuxel]

While not directly what you are mentioning, this may be of interest: #3218. You'll soon be able to add your own definitions to for repos locally.

//cc: Christof Marti (@chrmarti)

[bhack]

Are you talking about global override or overlay (partial override)?

[Chuxel]

bhack It is a global override not an overlay.

[bhack]

Yes here It more like I want to be update with the distributed configurations but I work with some small local changes (e.g. an extra mount, an extra env var etc..) or with some lines that was distributed commented (i.e. default CPU but I an on a GPU machine).

[WasabiFan]

I'd just like to bump this thread and share my use-case for something along these lines.

In my case, I would like to add an extra mount in the dev container for my personal use which doesn't affect the repository copy. I don't want to .gitignore the .devcontainer.json since that is a shared file which everyone edits. As far as I can tell, if you have a .devcontainer.json checked into your repo, there isn't a supported way to have user-specific configuration on top of that base container definition. It would make sense to me if you could add those in your user configuration, or add a .devcontainer-user.json which was expected to be gitignored.

[bhack]

Any progress on this?

[chrmarti]

If we want to overlay 2 JSON files, we need to consider the options for merging objects and arrays. Overwriting top-level properties might not always be the desired behavior, while merging properties (or adding elements) recursively excludes the option for removing properties (or elements).

[bhack]

We need something like https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays

[Chuxel]

Christof Marti (@chrmarti) Yeah this in my view is highly related to #3568. I think we ultimately need an inheritence model, ideally one that can use some sort of central registry as well. With what bhack has pointed out, and that we are seeing people placing dev container config in sub-folders, you can imagine a scenario where there is a GPU and CPU flavor of the config... if not other more dramatic differences.

If .devcontainer.json could be added to .gitignore, you could store a full .devcontainer folder somewhere else - say ${workspaceFolder}/dev/gpu. This .devcontainer.json file could then just include something like:

{
    "parent": "${workspaceFolder}/dev/gpu"
}

I've also heard about scenario driven dev container definitions that this would also work for (e.g. you're in front-end dev mode verses back end dev mode).

Allowing devcontainer.json properties to be overidden or merged, then becomes a natural extension. We'd need to determine property behaviors, but to some extent its a bit like having docker-compose.yml and then docker-compose.override.yml with tweaks. Certainly build.args is a good example of one I'd exepct to be of interest particularly if the dev container parent comes from somewhere else. The Codespaces team has examples as well.