mirror of
https://github.com/docker/build-push-action.git
synced 2025-08-20 10:23:34 +00:00
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*
|