go command not found in feature installation despite dependsOn on ghcr.io/devcontainers/features/go:1

[thediveo]

What happened?

Creating a new workspace from the locally cloned repository github.com/thediveo/enumflag fails. devpod fails to correctly configure and install a devcontainer feature that has a "dependsOn" on ghcr.io/devcontainers/features/go:1, in particular, when the dependent feature's install script runs and tries to invoke the go command, it cannot be found.

What did you expect to happen instead?

The workspace creation to succeed, as it does with VSCode and its devcontainer implementation.

How can we reproduce the bug? (as minimally and precisely as possible)

My devcontainer.json:

{
    "name": "enumflag",
    "portsAttributes": {
        "6060": {
            "label": "enumflag package documentation",
            "onAutoForward": "notify",
            "protocol": "http"
        }
    },
    "image": "mcr.microsoft.com/devcontainers/base:ubuntu-24.04",
    "features": {
        "ghcr.io/thediveo/devcontainer-features/local-pkgsite:0": {},
        "ghcr.io/thediveo/devcontainer-features/goreportcard:0": {},
        "ghcr.io/thediveo/devcontainer-features/go-mod-upgrade:0": {},
        "ghcr.io/thediveo/devcontainer-features/gocover:0": {
            "num-programs": "1",
            "race": true,
            "verbose": true,
            "html": true
        }
    },
    "remoteEnv": {
        "GOPATH": "/home/vscode/go",
        "PATH": "/home/vscode/go/bin:/go/bin:/usr/local/go/bin:${localEnv:PATH}"
    }
}

Local Environment:

• DevPod Version: 0.6.6
• Operating System: linux
• ARCH of the OS: AMD64

DevPod Provider:

• Local/remote provider: docker

Anything else we need to know?

[bkneis]

Hi @thediveo thanks for raising your issue. Reading the spec I believe you need to specify the dependant features in your devcontainer.json. Can you try adding ghcr.io/devcontainers/features/go:1 and ghcr.io/devcontainers/features/node:1 to your .devcontainer.json to see if this fixes the issue?

[thediveo]

I'm not sure I understand you here. The features themselves have their Go feature dependency set, including the one where devpod fails at (logs seem to indicate devpod also fails in other features, too). Having the devcontainer's meta data to list all transient dependencies sounds unreasonable to me. In fact, vscode's devcontainer spec implementation works correctly here. I mean, part of the spec is about recursive dependency resolution.

[bkneis]

I was reading https://containers.dev/implementors/features/#dependsOn and saw All Features indicated in the dependsOn property must be satisfied. I took this as the dependencies needed to already be satisfied before the feature can be installed by devpod, so the user could specify the parameters they wanted for the dependency. I could be wrong and you are right if the reference implementation automatically does this then that is a good indication devpod should. I'll take a deeper look into this later :) If you have anymore info or ideas for a fix please share, also the logs you mention would be great

[thediveo]

The "needed to be satisfied" IMHO is to be understood in contrast to the the installAfter, see https://containers.dev/implementors/features/#installation-order. Seriously, what use would https://containers.dev/implementors/features/#dependsOn have for the dev experience if a devcontainer needs to specify the transitive/recursive dependencies? None. I'm struggling with that we even discuss such basic behavior and user expectation here, more so, as Microsoft got it right out of the box.

[thediveo]

Here's the devpod.log from the failed attempt using a locally checked-out clone of https://github.com/thediveo/enumflag ... because trying to directly create a new workspace by cloning fails in devpod without no clear sign as to why it should fail on a public repo.

[thediveo]

Besides installation order there can be another source of problem if the path settings are interpreted differently between vscode devcontainers/devcontainers and devpod. The unit tests of my referenced features work correctly when tested using the devcontainer CLI command.