Build each architecture on its own runner instead of emulating arm64

[authorTom]

1.5.0 has a git tag and a GitHub Release but no published image. Three image builds in a row published nothing.

What's wrong

npm ci hangs indefinitely on linux/arm64 under QEMU emulation. From the run on the #21 merge:

23:18:37  #14 [linux/arm64 build 4/6] RUN npm ci     ← starts
23:18:41  #15 [linux/amd64 build 4/6] RUN npm ci     ← done in 4.3s
23:18:56  #21 [linux/amd64 stage-1 6/6] ...          ← amd64 finished the whole image
23:18:56  #14 [linux/arm64 build 4/6] RUN npm ci     ← last line
          ······ six hours of silence ······
05:18:14  ##[error]The operation was canceled.

Not a slow build — a hang. Reproduced three times: both main merges (32604849105, 32605380021) and the v1.5.0 tag build (32622498187, cancelled once the pattern was clear rather than burning another six hours).

Nothing in this repo caused it. v1.4.0 built in 44 seconds on 20 Aug. setup-qemu-action pulls tonistiigi/binfmt:latest — unpinned — so the emulation layer moved underneath us, and the workflow had no way to notice.

The fix

Each architecture builds on its own native runner and pushes an untagged image by digest; a merge job stitches the digests into one manifest list and puts the tags on that. ubuntu-24.04-arm is free on public repos.

Pinning binfmt instead would be guessing at a good version, would leave arm64 emulated and slow, and would leave the same unpinned-dependency exposure that caused this. Native runners remove QEMU from the question.

Tags are applied only on the manifest list, never per-architecture — two arch builds both carrying :latest would fight over the tag, last push winning.

Two things the logs made obvious

• timeout-minutes on every job. The default is six hours, which is exactly why each hang cost a full six before anyone heard about it. Now 30 (build) and 15 (merge).
• The image name is lowercased explicitly. metadata-action does this for you; docker buildx imagetools in the merge job does not — and authorTom has a capital T, which ghcr.io rejects outright. That would have failed the new merge step on its first run.

Also fail-fast: false, so one arch failing doesn't cancel the other — knowing whether it's "arm64 is broken" or "the build is broken" is the whole diagnosis.

Not fixed here

GitHub is force-running all six pinned actions on Node 24 because Node 20 is deprecated. It's a warning today, not the cause of this, and bumping six action majors doesn't belong in the same change as unbreaking the release.

After merge

main publishes :edge and :sha-… and proves the workflow works. Then re-run it against the existing tag — gh workflow run docker.yml --ref v1.5.0 — to publish :1.5.0, :1.5, :1 and :latest. The tag and Release need no changes.

🤖 Generated with Claude Code