Broken `build-arg` handling (requires `=`, ignores environment)

[andraxin]

Contributing guidelines and issue reporting guide

• I've read the contributing guidelines and wholeheartedly agree. I've also read the issue reporting guide.

Well-formed report checklist

• I have found a bug that the documentation does not mention anything about my problem
• I have found a bug that there are no open or closed issues that are related to my problem
• I have provided version/information about my environment and done my best to provide a reproducer

Description of bug

Bug description

Passing --opt build-arg:IMAGE to buildctl build results in an error:

error: invalid opt: invalid value build-arg:IMAGE

even though the environment variable IMAGE is set.

Given that BuildKit's own documentation of build-arg handling is fairly sparse,
a reasonable expectation is that the original Docker/Buildx behavior would be followed.

The simple workaround of passing --opt build-arg:IMAGE=$IMAGE avoids the error,
but that should not be necessary.

Reproduction

$ docker run --rm -it --entrypoint sh --privileged -w /root moby/buildkit
~ # printf 'ARG IMAGE\nFROM $IMAGE\nRUN echo working\n' > Dockerfile
~ # export IMAGE=alpine
~ # buildctl-daemonless.sh build --frontend dockerfile.v0 --local dockerfile=. --opt build-arg:IMAGE
error: invalid opt: invalid value build-arg:IMAGE
~ # 
$ 

Version information

$ docker run --rm moby/buildkit --version
buildkitd github.com/moby/buildkit v0.32.2 991535e0973488b6a429096d21fa13f81f2d89d8
$

Additional notes

I tracked down the issue to BuildKit's unifrom handling of ALL --opt arguments,
via ParseOpt and attrMap in opt.go and build.go, respectively.

Contrast that with Buildx's listToMap function that optionally references environment variables:
https://github.com/docker/buildx/blob/556e63ede01ff0321cb5dda26826accfec9374f6/commands/build.go#L782-L800

As expected, build-arg processing turns that on:
https://github.com/docker/buildx/blob/556e63ede01ff0321cb5dda26826accfec9374f6/commands/build.go#L115

[ravi-arnan]

I have a fix for this and will open a PR shortly.

The rejection comes from attrMap (cmd/buildctl/build/build.go), which errors on any --opt that has no =. Worth adding to your analysis: buildctl already sources a build arg from the environment today. loadOptEnv in cmd/buildctl/build/util.go propagates SOURCE_DATE_EPOCH into build-arg:SOURCE_DATE_EPOCH. So the valueless form is the odd one out rather than a new capability.

I am handling it in ParseOpt rather than in attrMap, since attrMap is also used by --local, where a missing value should stay an error. An environment variable that is not set gets dropped rather than passed as an empty string, so a default in the Dockerfile still applies, matching docker buildx build --build-arg FOO.