broken installsAfter on OCI repo

[aacebedo]

Hi,

I have a devcontainer.json file referring to 2 features, feature Bar and feature Baz. The features are hosted in an OCI registry. I am using vscode 1.97 and devcontainer extension 0.401.0

Feature Baz have an installAfter clause referring to feature Bar. The container build fails when reference to feature Baz in feature B is not exactly the same (with version) as the one in the devcontainer.json.

VSCode tries to install feature Bar without a version and does not find it. If I put only the id of the feature instead of the full feature reference, it does not work either disregading what is specified in https://containers.dev/implementors/features/#installsAfter.

Here is a redacted version of the files:

{
  "image": "ubuntu:latest",
  "features": {
    "registry.gitlab.com/foo/bar:0.0.1": {},
    "registry.gitlab.com/foo/baz:0.0.1": {},
  }
}

feature bar:

{
  "name": "bar",
  "id": "bar",
  "version": "0.0.1",
}

feature baz not working:

{
  "name": "baz",
  "id": "baz",
  "version": "0.0.1",
  "installsAfter": [
    "registry.gitlab.com/foo/bar" => Does not work, VSCode tries to install the feature literally version without version does not exist
  ]
}

feature baz not working:

{
  "name": "baz",
  "id": "baz",
  "version": "0.0.1",
  "installsAfter": [
    "bar" => Does not work, VSCode does not see feature at all
  ]
}

feature baz working:

{
  "name": "baz",
  "id": "baz",
  "version": "0.0.1",
  "installsAfter": [
    "registry.gitlab.com/foo/bar:0.0.1" => works
  ]
}

[chrmarti]

This seems to be a case we didn't catch with https://github.com/devcontainers/cli/issues/269.

[aacebedo]

So the original bug is not fixed? Shall it be reopened?

[chrmarti]

We can track this here. 👍

[georglauterbach]

@chrmarti I am also affected by this bug. It is the exact opposite of what the documentation on the installsAfter property says:

The Feature indicated by installsAfter can not provide options, nor are they able to be pinned to a specific version tag or digest. Resolution to the canonical name should still be performed (eg: If the Feature has been renamed).

That's quite bad because I assume that, in @aacebedo' example, when the version of bar is bumped to 0.0.2, the resolution process for the dependencies in installsAfter might not work as expected?