Image buildx CLI arguments

[Chuxel]

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.

microsoft/vscode-remote-release#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.

{
    "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.

[Trass3r]

I guess I'd have preferred buildArgs on the same level as runArgs for consistency. But admittedly, that would be confusing with buildArgs and build.args.

[Chuxel]

I guess I'd have preferred buildArgs on the same level as runArgs for consistency. But admittedly, that would be confusing with buildArgs and build.args.

Yeah, that's exactly the issue. Docker builds also support "args". Keeping it under build also helps convey that this is specific to a straight image build since Docker Compose has its own syntax to deal with this particular challenge. This is of particular note given some of the discussions around #74 and #10. cliArgs seemed reasonable under build - not sure what else to call it.

[cduran]

I guess I'd have preferred buildArgs on the same level as runArgs for consistency. But admittedly, that would be confusing with buildArgs and build.args.

Yeah, that's exactly the issue. Docker builds also support "args". Keeping it under build also helps convey that this is specific to a straight image build since Docker Compose has its own syntax to deal with this particular challenge. This is of particular note given some of the discussions around #74 and #10. cliArgs seemed reasonable under build - not sure what else to call it.

We could call it:
cliOptions, same wording as in Docker docs: docker docs
cliFlags, also used: Other Docker reference

[metaskills]

Found my way here because I am updating some of our internal features to the latest spec. I would be amazing if there was some way to pass GitHub Secrets (repo or org scope) during each feature that needs it. For example, we could clone other private repos, pre install packages (npm, ruby) from other private repos.

[jkeech]

I would be amazing if there was some way to pass GitHub Secrets (repo or org scope) during each feature that needs it.

@metaskills For Codespaces, secrets are set as environment variables during the docker build which can be referenced in the devcontainer.json as follows. I believe this could be used to extend down into the feature RUN layers as long as the Dockerfile has the ARG defined. I haven't tested the features scenario directly, but here's an example of getting a secret into a docker ARG:

{
    "build": {
        "dockerfile": "./Dockerfile",
        "args": {
            "MY_SECRET": "${localEnv:MY_SECRET}"
        }
    }
}

I created https://github.com/jkeech/codespaces-docker-args and set a Codespaces secret on that repo called MY_SECRET with a value of Shhh!!!. You can see that it ends up being used during the build of the Dockerfile:

The only thing to be careful of is that the any docker ARG can be recovered from the image later on, which might not be an issue for some devcontainers/repos, but could be an issue for others, particularly if prebuilding and sharing the generated image.

From https://docs.docker.com/engine/reference/builder/#arg:

Warning:

It is not recommended to use build-time variables for passing secrets like GitHub keys, user credentials etc. Build-time variable values are visible to any user of the image with the docker history command.

Refer to the RUN --mount=type=secret section to learn about secure ways to use secrets when building images.

[metaskills]

Thanks! This is useful, but as I understand it I am personally blocked from using this sweet hack in few ways:

1. Run onCreateCommand and updateContentCommand in prebuilt images (not pre-built Codespaces) cli#150
2. Lifecycle hooks support for dev container features #60
3. Could not resolve Private Feature when pre-building a Codespace (not a container image) cli#277

But once these are done I would gladly entertain that method.

[Chuxel]

@metaskills (1) should not be required for Codespaces. That's more about local or other VMs. (3) should just require a priv update - commented there.

[James-Mart]

This would be a very welcome addition. Has there been any internal discussion or movement on this topic? microsoft/vscode-remote-release#3545 is still continuing to get upvotes and attention...

[c-ameron]

Would it be possible to also include using docker buildx bake has well? Bake as slightly more features than just cli arguments. It would be really useful in my use case where we use it to build containers. Thanks