Offer configs from dev.containers.repositoryConfigurationPaths and repository when both exist

[chrmarti]

          In lieu of this feature, I had been using the precedence mentioned in https://github.com/microsoft/vscode-remote-release/issues/3218#issuecomment-646636472 to do something like this workflow:

• Create a directory like ~/.config/devcontainers
• Configure the new directory in dev.containers.repositoryConfigurationPaths
• Copy a checked-out repo's .devcontainer/devcontainer.json to ~/.config/devcontainers/github.com/$ORG/$REPO/.devcontainer/
• Customize the version in ~/.config/devcontainers as needed
• Rebuild and Reopen in Container. The precedence mentioned above ensured my customized version gets used

However, this workflow seems to have stopped working — I'm not sure when, unfortunately I don't recreate my containers very often. Now, the checked-in devcontainer.json seems to take precedence over my local one (as initially proposed in https://github.com/microsoft/vscode-remote-release/issues/3218#issuecomment-646608062). I can see from the logs that the label=devcontainer.config_file refers to the repository version, rather than my local ~/.config file.

Has anyone else noticed this change / should I file a new issue for it? Without this workflow I can't seem to come up with any way at all to customize my local container, other than deleting the repository's .devcontainer folder every time I want to use it (obviously a huge pain!).

Originally posted by @ian-h-chamberlain in https://github.com/microsoft/vscode-remote-release/issues/3279#issuecomment-1692379932

[chrmarti]

This workflow most likely broke when we added support for multiple devcontainer.json in a single repository.

[srpouyet]

Hi, I'm running into exact this issue - it would make more sense to me that any local configurations take precedence over any dev container configuration present in the repositories. My use case is that I'd like to be able to locally override my organisation's dev container config - I don't want to modify the repository version because that'll affect all the engineers in my org, which is a huge pain. If anybody is aware of a other workarounds -besides deleting the repo version- that would be much appreciated! 🙏