mirror of
https://github.com/docker/build-push-action.git
synced 2025-08-20 10:23:34 +00:00
616bee01ad
The test was hardcoded to expect arm64 platform, causing failures on AMD runners. Now checks actual host architecture dynamically. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
67 lines
3.0 KiB
Markdown
67 lines
3.0 KiB
Markdown
# Incorrect `--platform` flag when creating remote Buildx builder
|
||
|
||
## What is the bug?
|
||
When the action spins up a **remote** Buildx builder it always adds the option
|
||
|
||
```bash
|
||
docker buildx create … --platform linux/amd64 …
|
||
```
|
||
|
||
regardless of the `platforms:` input provided by the user or the
|
||
architecture of the runner that is executing the job. In the log excerpt
|
||
observed from customers the runner is `linux/arm64`, the user requested
|
||
`platforms: linux/arm64`, yet the builder is created with
|
||
`--platform linux/amd64`.
|
||
|
||
## Why does this happen?
|
||
The helper that assembles the arguments for `docker buildx create` (see
|
||
`context.getRemoteBuilderArgs`) hard-codes `--platform linux/amd64` instead
|
||
of propagating the caller-supplied platforms list or detecting the host
|
||
architecture. Because this code path is executed every time a remote
|
||
builder is requested, every customer who uses the remote driver is affected.
|
||
|
||
## How does it affect customers?
|
||
* The builder advertises only the amd64 platform even on arm64 runners.
|
||
* Buildx may silently fall back to QEMU emulation inside the builder,
|
||
slowing builds and producing confusing CPU usage patterns.
|
||
* Cache keys are generated per platform; advertising the wrong platform can
|
||
reduce cache hits or create duplicate caches that waste storage.
|
||
* Logs show a mismatch between the declared build target (`linux/arm64`) and
|
||
the builder's reported platform (`linux/amd64`), which is a common source
|
||
of support tickets and undermines trust in the tool.
|
||
|
||
Most jobs still succeed because Buildx can emulate the foreign architecture,
|
||
so customers rarely see hard failures. They do, however, experience longer
|
||
build times and uncertainty about what is really happening.
|
||
|
||
## Proposed fix
|
||
1. **Propagate user intent** – Use the `platforms` input when constructing
|
||
`docker buildx create` arguments:
|
||
|
||
```ts
|
||
// pseudo-code
|
||
const platformsArg = inputs.platforms.join(',');
|
||
if (platformsArg) args.push('--platform', platformsArg);
|
||
```
|
||
|
||
2. **Fallback to host arch** – If the user does not supply `platforms`,
|
||
derive the native architecture from `process.arch` or
|
||
`docker info --format '{{.Architecture}}'` and pass that instead.
|
||
|
||
3. **Remove the flag** – Alternatively, omit `--platform` entirely and let
|
||
Buildx detect the platform list from connected BuildKit workers.
|
||
|
||
## Benefits of fixing it
|
||
* **Accurate builder metadata** – `buildx inspect` will reflect the actual
|
||
worker platforms, eliminating confusion in logs and support tickets.
|
||
* **Performance gains** – Native arm64 workers will build arm64 images
|
||
without QEMU emulation, reducing build times significantly (often 2-3×).
|
||
* **Higher cache efficiency** – Cache entries will be generated for the
|
||
correct platform, improving reuse across builds and cutting storage
|
||
costs.
|
||
* **Foundation for multi-platform builds** – Correct handling of the
|
||
`platforms` flag is prerequisite for future work on native multi-platform
|
||
clusters.
|
||
|
||
---
|
||
*Prepared by: build-push-action investigation* |