devcontainers
`features` and Dockerfile `ARG` values should be able to share arguments through the config
@samruddhikhandale has run into a problem where she wants to be able to share configuration arguments in both the build's Dockerfile, and inside of a feature's install script.
One idea I have for this, is that we automatically expose the build.arg arguments in the devcontainer.json to all feature script.
Eg:
{
"build": {
{
"dockerfile": "./Dockerfile"
"args": {
"MY_USERNAME": "josh"
}
},
"features": {
"/features/go": "latest",
"/features/java": "latest"
}
}
/features/go/install.sh
#!/bin/bash
...
echo $MY_USERNAME
...
/features/java/install.sh
#!/bin/bash
...
echo $MY_USERNAME
...
./Dockerfile
ARG MY_USERNAME=adam
RUN echo ${MY_USERNAME}
Another idea is moving the "args" property to the top-level, to indicate they arguments should be shared with other customizations, etc that come along.
Could you link to the relevant code? My initial thought is that features should be self-contained and not access build arguments provided for the user's Dockerfile. Could the feature add an option for itself?
USERNAME was the main argument needed, while building the image with multiple features.
Adding that as an option to the feature could work, we are already doing that for the common feature.
@joshspicer any other thoughts?
Yea, this is something @samruddhikhandale has found a need for (in some way or another). I imagine this could be useful for an organization where they have n features that all need certain options available in all their features.
Not sure what you need the USERNAME for, but it might make sense to just loop over all regular users and apply it for all. Oftentimes there will be only one, but that approach has the nice side-effect of also working with multiple user accounts.
For this particular one we could standarize on adding environment variables before features are built that represent containerUser and remoteUser.
If this case ends up being commong it could be useful for all features.
