devcontainers / devcontainers/spec
Image buildx CLI arguments
- Dominant language
- No language data
- Stars
- 5.7k
- Forks
- 496
- PR merge metrics
- No merged PRs in 30d
Description
Related to #74 and #18, as devcontainer.json drives builds for images that are self-contained there is an increasing likelihood for developers to need to be able to apply build time arguments not supported directly by the dev container CLI.
https://github.com/microsoft/vscode-remote-release/issues/3545 has continued to gain up-votes and has several examples of this problem:
- ` --ssh=default`
- `--add-host=archive.ubuntu.com:160.26.2.187`
- `--network=host`
The common theme here is network access for the build itself. One option is to try to adopt all of these types of arguments under the `build` property, but there's a risk of always being out of date. Other examples include:
- Specifying a custom builder (for buildx)
- Allowing extra privileges for just the build
- Passing in secrets (via `--secret`)
People are going so far as to use `initalizeCommand` to do the build instead of using built in support due to these gaps.
While `secret` in particular could be added to the spec, we likely need a "safety valve". Therefore, I'd propose we include a `build.cliArgs` property. similar to `runArgs`, but focused on the CLI arguments of buildx instead.
```json
{
"build": {
"dockerfile": "Dockerfile",
"args": {
"foo": "bar"
},
"cliArgs": [ "--ssh=default" ]
}
}
```
Popular arguments should be moved into the spec itself (like #2 for runArgs), but this provides an interim solution and a way to handle less common scenarios.
Contributor guide
Assessment
This issue has not been assessed yet.