If mcr.microsoft.com/vscode/devcontainers/base:0-focal is a manifest list(defines its platform in the manifest) then it will throw an error. On single platform images, it does not for backward compatibility.

Is there a case in which getting an image of not the specified --platform can be useful? If so, it may be better have this behavior as an opt in (e.g. introduce a --allow-platform-fallback) instead of the default.

At least buildx should show a warning.

I agree with @andyli. Unless I'm missing something, as it stands today, the only way to prevent an automated build system using buildx from happily building and pushing images for the wrong platform is to parse the Dockerfile and check each FROM statement with a complicated script that calls the Docker registry API to figure out if the base image is a v2/multi-arch image or not (which is what I'm doing). This is extremely disconcerting and frankly, dangerous. Even an opt-in flag like --require-platform or even --min-manifest-version=2 or --verify-platform or something would be a big improvement.

@thaJeztah @crazy-max I think we have given people enough time to move away from broken builders where the config and binary arch does not match and upgrade to multi-arch. I'm ok with breaking backward compatibility and making this case error. We could provide a build-arg to bypass the error. WDYT?

Just want to point out another really confusing thing here:

If you run a docker image inspect on the newly-built image, it shows "Architecture": "arm64" even though it is amd64.

This may be for some sort of backward compatibility (?) but it was a big red herring for me when I was investigating.

@tonistiigi Any update on this issue? I came across this behaviour and it took me by surprise too.

I recently split a Dockerfile into smaller files and one of the build stages used FROM --platform= for a stage to use a different RUN instruction based on the platform as different packages were needed to install / build.

When using docker buildx bake to build the sequence of files and leverage context to reference earlier stages from prior Dockerfiles, I noticed that regardless of where I specified explicitly the linux/amd64 platform, it was always running the 2nd stage in a Dockerfile for the linux/arm64 platform.

Just adding another scenario with local image builds where this was a surprise as I didn't want the ARM64 stage as part of the AMD64 build, thinking FROM --platform would have been respected.

@polarathene Create a separate issue with a reproducer. It is unlikely that this is the same issue if you are combining builds with bake using named contexts.

Count me as yet another person that found this behavior beyond surprising. We were trying to build a multi-arch image using --platform linux/arm64,linux/amd64. We do have some legacy images where there is no arm64 base, and my expectation was that either it would build just for x86 and give warnings for arm, or else it would generate an error for the whole build. I could have worked with either behavior.

Instead, it "successfully" built two images, apparently multi-arch when checked from the outside. Running docker buildx imagetools inspect shows both architectures. Everything in the build process looked successful. But then doing a docker run --platform linux/arm64 and docker run --platform linux/amd64 both show that they're actually both x86. (The fact that the run command didn't complain that the architecture mismatched was also surprising and distressing!)

Fallbacks are always risky without some compensating control to allow strictness to be enforced, but generating something totally contrary to the inputs while simultaneously claiming that they do, and not generating a single warning... this is a critical bug in my view. It's hard to see how it's been open since 2021.