Handling of features and version updates by things inside the feature (dependabot/renovate)

[Roemer]

I have a bit of a hard time understanding how auto-updating especially for the features in a devcontainer.json can work.
The main issue I have is that a feature itself has a version but the things that are installed by the feature can also have one or more version numbers.
As a simple example the go feature has a version number (1.3.0 currently) but the installed go version (which can also be specified by the version property) is independent of the features version number.
So if I have for example:

"features": {
	"ghcr.io/devcontainers/features/go:1.3.0": {
		"version": "1.21.6"
	}
}

I would want it to update the version of go to 1.22.0.

It gets even more complicated when looking at a feature like common-utils where a lot of tools (wget, htop, zip, ...) are installed and each has its own version. I don't see how one can auto-update this with the current available possibilities.

What I would see is some kind of cli command like devcontainer features versions which invokes a script or some other method in a specific feature that returns a hash-map of version numbers that is provided by the feature like:

{
    "wget": "1.21.4",
    "htop": "3.3.0",
    "zip": "3.0-13"
}

This map could be persisted and checked by renovate/dependabot and generate a PR if one of the things installed by a feature gets a new version number.

Or is all that already possible somehow and I just didn't find it?
Many thanks for input.

[samruddhikhandale]

Hi 👋

Thanks for the detailed question.

What I would see is some kind of cli command like devcontainer features versions which invokes a script or some other method in a specific feature that returns a hash-map of version numbers that is provided by the feature like:

Are you looking for a command which outputs the available (current/latest) versions for the Feature (ie 1.3.0 in the above scenario of go)?

If so, then we already have a devcontainer outdated command. See 👇

@Roemer Would that help? Let me know if I am misunderstanding anything.

[Roemer]

Thank you for your answer, that is already good to know but my main issue is the handling of things installed by a feature. So for example the go feature installs go in a specific version and I somehow want to know, if there is a never version of go that is installed by the feature.

[samruddhikhandale]

Got it, so you are more interested in the version of the tooling (Go in this case) installed by the Feature?

Currently, I don't believe we have an easy way to identify it. If you pin the version to latest, then on every build, it will install the latest version that's available in the market. However, if you pin to a specific version, then it won't be easy to find the newer version (if any) that would be installed by the Feataure (unless you look at official Go releases which are used by the Feature for installation OR in parallel let the Feature install latest version and then compare them)

In case you have any ideas on how to simplify things, feel free to open an issue in https://github.com/devcontainers/spec

[Roemer]

I am still playing around with it a lot but did not find a good solution yet. One approach would be that the options from features would support variables. So for example:

	"features": {
		"ghcr.io/devcontainers/features/go:1": {
			"version": "$GO_VERSION"
		}
	},

which seems to currently not work yet. I tried containerEnv, remoteEnv and setting the variable system wide. Is there right now to achieve this?