devcontainers / devcontainers/spec

Image buildx CLI arguments

Open
#85 9 comments 14 reactions 0 assignees View on GitHub
proposal
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.