Support for referencing feature option values in containerEnv

[rickardgranberg]

We have a case where we need to define a Container env variable, that depends on the value of an option.

Although possible to inject the env variable in .profile, .bashrc or similar in install.sh, this causes an issue when using the build image in CI/CD, specifically in Azure Pipelines when bash is launched with the --noprofile --norc flags.

As an example:

{
    "id": "some-feature",
    "version": "0.0.1",
    "options": {
        "version": {
            "type": "string",
            "proposals": [
                "latest"
            ],
            "default": "latest",
            "description": "Select or enter a version"
        }
    },
    "containerEnv": {
        "FEATURE_HOME": "/opt/feature/<need-version-here>/bin",
    }
}

Maybe something similar to the pre-defined variables ${localEnv:VARIABLE_NAME} would work, like ${option:optionName}?

In context:

{
    "id": "some-feature",
    "version": "0.0.1",
    "options": {
        "version": {
            "type": "string",
            "proposals": [
                "latest"
            ],
            "default": "latest",
            "description": "Select or enter a version"
        }
    },
    "containerEnv": {
        "FEATURE_HOME": "/opt/feature/${option:version}/bin",
    }
}

[joshspicer]

@samruddhikhandale This seems useful for a lot the Features in the devcontainers/features repo, no?

[samruddhikhandale]

Yeah, this seems pretty helpful. For such scenarios, we are currently creating a new folder (say current) and symlinking the version of the feature.

[Roemer]

This would be really helpful. I need to create an internal package for Java (with custom certificate / config) and could use the exact version from the options to point to the java installation folder (including the version in the name).

Also, some kind of conditions would also be helpful. Like in the current java package, one can install gradle and maven or not but the paths to them are always added. Not a big deal but could be nicer. I am not entirely sure how that could look like as this can be fairly dynamic where the logic is inside the install.sh file.

[phorcys420]

This would be really helpful. I'd like to let users of my feature choose where to install the software but still add the resulting folder to the PATH, currently the only way would be to add the variable to /etc/environment or in /etc/profile.d, it'd be way better if it was built-in!

[sidecus]

This would be really helpful. I'd like to let users of my feature choose where to install the software but still add the resulting folder to the PATH, currently the only way would be to add the variable to /etc/environment or in /etc/profile.d, it'd be way better if it was built-in!

Not a Linux expert, however it seems /etc/environment and /etc/profile.d won't work since docker exec etc. uses non-login shells which will ignore them. You can observe this behavior in the feature starter test case runs by injecting environment variables into /etc/environment in install.sh.

[phorcys420]

This would be really helpful. I'd like to let users of my feature choose where to install the software but still add the resulting folder to the PATH, currently the only way would be to add the variable to /etc/environment or in /etc/profile.d, it'd be way better if it was built-in!

Not a Linux expert, however it seems /etc/environment and /etc/profile.d won't work since docker exec etc. uses non-login shells which will ignore them. You can observe this behavior in the feature starter test case runs by injecting environment variables into /etc/environment in install.sh.

Yeah I guess, I said this because I was fine for it to be login-shell only for the time being, realistically the only case where non-login shells matter with PATH is if a feature depends on another one, but then if you know the feature is installed you can just source the environment in your installation script.