feat(agent/agentcontainers): add feature options as envs #18576
Conversation
| // OptionsAsEnvs converts the DevcontainerFeatures into a list of | ||
| // environment variables that can be used to set feature options. | ||
| // The format is FEATURE_<FEATURE_NAME>_<OPTION_NAME>=<value>. | ||
| // For example, if the feature is: | ||
| // | ||
| // "ghcr.io/coder/devcontainer-features/code-server:1": { | ||
| // "port": 9090, | ||
| // } | ||
| // | ||
| // It will produce: | ||
| // | ||
| // FEATURE_CODE_SERVER_PORT=9090 |
There was a problem hiding this comment.
I can foresee an issue potentially arising with this approach.
"go": {
"server-port": 9090
},
"go-server": {
"port": 9091
}
Would both produce FEATURE_GO_SERVER_PORT but they have different values
There was a problem hiding this comment.
yeah we might want something like FEATURE__GO_SERVER__PORT / FEATURE__GO__SERVER_PORT
edit: jinx 😄
There was a problem hiding this comment.
Good call-out, not sure how we should fix though. Use __ as separator? Include the :1 as _1?
There was a problem hiding this comment.
I think __ could work as a separator, it might still have the same issue if people want to double up on their - but I think that is unlikely.
There was a problem hiding this comment.
Seems we had the same idea @johnstcn, let's go with __ although using _OPTION_ might also work. Like FEATURE_GO_SERVER_OPTION_PORT. The risk of collision is so small that if it does happen, somebody can think about why they chose to call an option option.
There was a problem hiding this comment.
I think double-underscore separator should work fine.
edit: jinx again, but I do like your OPTION_OPTION as well!
There was a problem hiding this comment.
Unless you guys are greatly opposed I'd actually like to go with the _OPTION_ approach. Seems more human friendly.
There was a problem hiding this comment.
@mafredri I prefer your suggestion, go with _OPTION_.
Since
devcontainer-feature.jsondoes not support referencing options anywhere outside the feature installation, especially within the JSON itself, this change implements a work-around by defining environment variables based on the feature options that we can use in our features.This allows us to define a dynamic URL for e.g. the
code-serverfeature.