Publish multi-arch image (add linux/arm64) #10
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
forge.isohex.uk/isohex/edge-router:latestis currentlylinux/amd64only. On Apple Silicon dev machines (devinfra under OrbStack) it runs under Rosetta emulation — functional, but slower to start and heavier on CPU than a native build.Add
linux/arm64to the CI image build (e.g.docker buildx build --platform linux/amd64,linux/arm64) so the manifest serves the native architecture on both the homelab amd64 hosts and arm64 dev machines.Noticed 2026-07-27 while verifying the devinfra stack after the OrbStack migration.
arm64 publishing is live (via the self-hosted Mac runner)
Added
.forgejo/workflows/docker-publish-arm64.yml(commit69e816a). On every push tomainthemacos-arm64runner builds a nativelinux/arm64image (OrbStack, no emulation) and pushes:develop-arm64,:<version>-arm64,:<sha7>-arm64; on av*tag it pushes:<tag>-arm64+:latest-arm64. First green run: task 362. Verified:develop-arm64islinux/arm64in the registry.Deliberate design choice: separate
-arm64tags, NOT a combined multi-arch:latestProduction (Roku, amd64) pulls
:latestvia Watchtower and must never wait on the laptop. A true combined multi-arch manifest can only be assembled once both arches build, which would couple prod deploys to the intermittent Mac runner. So the amd64 flow (docker-publish.yml/docker-release.yml) is untouched, and arm64 lives on its own-arm64tags. The laptop points its edge-router at…:latest-arm64/…:develop-arm64. Intermittency is a non-issue: the laptop is both the only arm64 builder and the only arm64 consumer, and Forge queues the job until it reconnects.Two host-runner gotchas fixed along the way
actions/checkoutaction can't run → the workflow clones manually withgit.dockerCLI lives in~/.orbstack/bin, which isn't on the runner's launchd PATH → the workflow prepends it (otherwisedocker: command not found).If you'd rather have a single
docker pull …:latestthat auto-selects arch (true multi-arch manifest), that's doable but reintroduces the prod-coupling above — leaving this open in case you want that later; otherwise it can be closed as resolved by the separate-tags approach.Resolved — images are multi-arch ✅
edge-routeris now published as proper multi-platform images. Each of these is a single OCI image index carrying bothlinux/amd64andlinux/arm64, sodocker pullauto-selects the right arch on any host::latest:develop:69e816a(and:v1.0.6-69e816a)The old arch-split
:*-arm64tags were removed, and the arm64 CI workflow no longer emitslatest-arm64(commiteb9fbb6) —:latestis the multi-arch manifest.How they're produced today (semi-manual)
docker-publish-arm64.yml, via buildx/BuildKit — PR #17), publishing:*-arm64tags.--platform linux/amd64) because the CI amd64 build is currently down.docker buildx imagetools create(no rebuild needed).What's deferred (not blocking this ticket)
Fully automated multi-arch in CI needs the amd64 build working in CI, which is blocked on the roku
forgejo-runnerfailing every job atactions/checkout— tracked in james.oates/homelab#6. That CI automation is being folded into the in-progress server rebuild.Closing: the deliverable (multi-arch image available for both arches) is met. The CI-automation remainder is carried by james.oates/homelab#6.