Support multiple developer roles via multiple files in .devcontainer folder

[zfields]

Depending on the developer role, you may have a different experience interacting with a code base through a container (e.g. different credentials, user, context, Dockerfile, etc...). All these things are prescribed by .devcontainer/devcontainer.json.

I would like to be able to specify multiple configuration files (as opposed to only devcontainer.json) in the .devcontainer folder, then be prompted to select one when I choose to "Open Folder in Container...", unless there is only one, in which case I want it to be smart enough to select it for me.

Relates to: Remote - Containers

[mraarone]

I'd also like support for multiple devcontainer.json definitions. GitHub Codespaces doesn't support the -e "SSH_AUTH_SOCK" flag nor mounts of said value, for understandable security reasons. But locally or running on a remote VSCode instance, it makes sense to forward security information from the developer's host and mounting passwd/group/shadow/sudoers files for passthrough user security experience in a development environment. GitHub Codespaces refuses to start any devcontainers.json file with mounts in it.

I attempted to use the new feature created 5 days ago for default variable values to make the security mount use /dev/null and /dev/null, but even that mount is considered insecure by Codespaces. Having RunArgs with any mounts or environment variable mappings is refused.

Docker Desktop also cannot set a default runtime, such as a CUDA GPU-enabled one, so there is no current work around for not setting a RunArg with "--gpu all" which fails on the Codespace docker command on any of the default available Codespace environments. However, when run locally, being able to use a devcontainer definition that had this docker configuration for GPU accelerated Data Science compute capabilities would be fantastic. We are resorting to an external GitHub runner that's GPU-enabled and our CI/CD pipeline for an MLOps-style ML training/testing capability without "contacting sales" for a Codespaces GPU environment that won't crash. The "--gpu all" conflict is a limiting factor for a fluid Codespaces experience without a multiple devcontainer definition capability.

Having support for multiple devcontainer.json definitions per environment or per role would be beneficial. We are resorting to use no default devcontainer.json file, and instead using the [VSCode - Remote SSH - Open] badge to point to a non-default devcontainer definition file, and not using the Green "Code" drop down to create a codespace, but instead the "Manage Codespaces" page that allows for a dropdown of different definition files. Having a way to scan through the available devcontainer definitions would be a best scenario approach, and hiding that all in a single devcontainer.json would be fantastic.

[bamurtaugh]

Thanks for opening! I believe this is covered by devcontainers/spec#6, but please let me know if it's different.

[zfields]

Looks like the specification considerations multiple roles and how they would integrate into other tools, but I didn't see anything about the UI.

In my original request, I also asked for a UI update.

... then be prompted to select one when I choose to "Open Folder in Container...", unless there is only one, in which case I want it to be smart enough to select it for me.

If I missed it in the specification, forgive me, it was rather long and dense.

[bamurtaugh]

I believe the linked issue will cover all-up support for multiple dev containers, both technically and UI-wise in Remote-Containers.

[Chuxel]

This has not been implemented in the UI of the Dev Containers extension yet. Let's use this issue to track that since I'm not seeing another one.

[chrmarti]

Tracked as #7548.