buildx

The metadata check is part of the builds image pull process. The step can resolve a `FROM repo/image:tag` reference to the content sha the tag points to, and then if required fetch the content. In any case, recent-ish (maybe 24+) versions of docker default to a "prefer local" mode in buildkit so a local cached entry will be returned first if possible before any remotes are resolved. Out of interest, what docker/buildx/buildkit versions were attempting the connection? We ran into this on some container builds that run offline last year some time and I'm wondering if it was due to some ancient docker, as that flag appears useless on current docker. - https://github.com/docker/buildx/blob/7b1ec7211d871dfba53b10...

This is great! I’ve been waiting a long time for this and it seems like more debug features are in the pipeline too: https://github.com/docker/buildx/issues/1104 Docs: https://docs.docker.com/engine/reference/commandline/buildx_...

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that they bundle binfmt into the buildkit docker image <https://github.com/moby/buildkit/blob/v0.12.5/Dockerfile#L11...> which itself is compiled against a static copy of qemu <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/D...> with various /proc/sys/fs/binfmt_misc wizardry <https://github.com/tonistiigi/binfmt/blob/deploy/v6.2.0-26/c...> We ended up switching to using multiarch/qemu-user-static:7.2.0-1 <https://hub.docker.com/layers/multiarch/qemu-user-static/7.2...> which also mutates binfmt_misc in buildx's context in order to exec the static copy of qemu in it but I find their shell script much more legible about what's going on: <https://github.com/multiarch/qemu-user-static/blob/v7.