buildx bake with --print now requires a daemon
I'm using buildx bake in a docker image without a daemon in a CI process for preparing a docker-bake.json for future build. In the image, I installed docker buildx with :
# usefull for doing a "docker-buildx bake --print" which does not require docker deamon to run
COPY --from=docker/buildx-bin /buildx /usr/local/sbin/docker-buildx
This does not work anymore :
ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Simple repo to reproduce the issue :
https://github.com/MaximeWeyl/docker-buildx-bug-reproduce
Seems to happen since 0.9.0, works fine with 0.8.2:
# syntax=docker/dockerfile:1
FROM docker
COPY --from=docker/buildx-bin:0.8.2 /buildx /usr/libexec/docker/cli-plugins/docker-buildx
COPY <<-"EOT" ./docker-bake.hcl
target "default" {
dockerfile = "Dockerfile.webapp"
tags = ["docker.io/username/webapp:latest"]
}
EOT
RUN docker buildx bake --print
#11 [stage-0 3/4] COPY <<-EOT ./docker-bake.hcl
#11 CACHED
#12 [stage-0 4/4] RUN docker buildx bake --print
#0 0.139 {
#0 0.139 "target": {
#0 0.139 "default": {
#0 0.139 "context": ".",
#0 0.139 "dockerfile": "Dockerfile.webapp",
#0 0.139 "tags": [
#0 0.139 "docker.io/username/webapp:latest"
#0 0.139 ]
#0 0.139 }
#0 0.139 }
#0 0.139 }
#12 DONE 10.2s
Have not bisect yet but seems to occur when loading the instance here: https://github.com/docker/buildx/blob/105c214d15802358e2cd02622a20c5803aa1ec5e/commands/bake.go#L89
~Might be an upstream issue with docker/cli since we vendor master (22.06-dev) (cc @thaJeztah) in 0.9.0. Will take a closer look.~
Yes, I agree this is OK with 0.8.2, I downgraded.
Found the culprit: https://github.com/docker/buildx/blob/105c214d15802358e2cd02622a20c5803aa1ec5e/commands/util.go#L74
Long story short - since 0.9 we are now checking the context builder endpoint to make sure it's reachable before returning the instance: https://github.com/docker/buildx/pull/1129#issuecomment-1195542481.
For bake --print it's necessary to have a working builder if using a remote definition but for local files I guess we could add an exception.