Inconsistent behaviour of dev container local features depending on configuration location

Summary

VSCode supports users to specify locations other than the repository itself for providing dev container configurations.

I find that helpful, and am also trying to use dev container local features. These are useful for configuring things for personal use, without having to worry about publishing them.

Unfortunately, there are inconsistencies with dev container local features failing to build, when dev container configurations are not part of the repository folder being opened.

(If the answer is "this is not supported", it is not obviously documented anywhere in VSCode's documentation that I could find. Recording this issue may help people searching the issue tracker, at least.)

Working behaviour with a simple dev container

If I have a simple dev container configuration inside a cloned repository, with, for example, the sample hello feature:

/home/myaccount/src/
  github.com/
    some-owner/
      some-repo/
        …other repository files…
        .devcontainer/
          devcontainer.json
          hello/
            devcontainer-feature.json
            install.sh          

that works as expected.

That is:

• I open the /home/myaccount/src/github.com/some-owner/some-repo folder in VSCode
• I build the dev container
• I can run /usr/local/bin/hello that the feature adds within the dev container.

All good.

Using a dev container configuration path outside of the repository

VSCode helpfully gives the option to store dev container configurations elsewhere.

That's with the Dev > Containers: Repository Configuration Paths option for dev containers. It is defined as:

List of additional paths to search for repository configurations.

If I set that to an absolute path /home/myaccount/devcontainer-configs, and move the working dev container configuration from my cloned repository to:

/home/myaccount/devcontainer-configs/
  github.com/
    some-owner/
      some-repo/
        .devcontainer/
          devcontainer.json
          hello/
            devcontainer-feature.json
            install.sh

What I get is a failure on opening the /home/myaccount/src/github.com/some-owner/some-repo folder in VSCode and building the dev container:

[1569 ms] Resolving Feature dependencies for './hello'...
[1569 ms] * Processing feature: ./hello
[1569 ms] Local disk feature.
[1569 ms] Local file path parse error. Resolved path must be a child of the .devcontainer/ folder.  Parsed: /home/myaccount/devcontainer-configs/github.com/some-owner/some-repor/.devcontainer/hello
[1572 ms] Error: ERR: Feature './hello' could not be processed.  You may not have permission to access this Feature, or may not be logged in.  If the issue persists, report this to the Feature author.

I think that this is due to the way the devcontainers CLI works, which checks for the workspace root.

This is also part of the specification:

The project must have a .devcontainer/ folder at the root of the project workspace folder.

Similarly, you get similar feature failures if you try configuring a feature from within the user's "personal" dev container configuration directory, say /home/myaccount/.config/Code/User/globalStorage/ms-vscode-remote.remote-containers/configs, for the same reason: it's not in the workspace root.

Fixes?

I'm not sure it is possible to fix without changing the CLI or the spec. So what VSCode provides here, while useful, does not directly support local features, except via workaround (see below).

At the least, it would have saved me working this out if it were documented somewhere.

That's compounded by the devcontainers CLI error:

Resolved path must be a child of the .devcontainer/ folder.

which is unhelpful. My feature path is inside .devcontainer in both cases 🙃 — what is meant is that it needs to be inside the workspace root's /.devcontainer folder.

(I realise that this is not specifically a VSCode error message, and is one for the devcontainers CLI issue tracker though.)

Wonky workaround?

Inverting the relationship between configuration and repository seems to be a workaround.

What we can do instead is open the external dev container configuration folder in VSCode, and change the default source code mount there to point to the original cloned repository.

1. Edit the devcontainer.json to contain something like:

   "workspaceFolder": "/workspaces/some-repo",
   "workspaceMount": "type=bind,source=/home/myaccount/src/github.com/some-owner/some-repo,target=/workspaces/some-repo",
   

2. Open the dev container configuration folder in VSCode

and then the dev container local feature works 🥳, and everything else also seems like it works, though I've not fully tested it.

See the VSCode documentation on the default source code mount.

It would be preferable if this were just supported directly though.