ci: build and publish arm64 container images natively

[zarcen]

Summary

bink CLI, cluster, and DNS images are amd64-only, blocking arm64 support for bootc-operator (bootc-dev/bootc-operator#145). None of the three cross-compile: the CLI links CGO, cluster/DNS are pure RPM installs. This builds each arch natively (ubuntu-24.04, ubuntu-24.04-arm), then assembles a v2s2 manifest list in a separate push job, mirroring bootc-operator's existing pattern (bootc-dev/bootc-operator@7b3b091).

Testing

Dispatched all three workflows with push: false on this branch from my fork. Both arches built successfully for all three images, including the CGO build. The push/manifest job itself needs GHCR write access and wasn't exercised here; its logic mirrors bootc-operator's already-merged manifest job.

How to validate

gh workflow run build-bink-image.yaml --ref bink-arm64-ci-images -f push=true
gh workflow run build-cluster-image.yaml --ref bink-arm64-ci-images -f push=true
gh workflow run build-dns-image.yaml --ref bink-arm64-ci-images -f push=true

on a fork, or merge and watch the real push run on main.

Validation result

• bink-image: https://github.com/zarcen/bink/actions/runs/35033958933
• cluster-image: https://github.com/zarcen/bink/actions/runs/35034015294
• dns-image: https://github.com/zarcen/bink/actions/runs/35034030326

Also tested to really push to my ghcr so I can sanity check the image manifest:

docker pull ghcr.io/zarcen/bink/dns:latest
docker pull ghcr.io/zarcen/bink/cluster:latest
docker pull ghcr.io/zarcen/bink/bink:latest

Started a local bink cluster locally on Apple Silicon (arm64) :

# loading arm64 images to podman
podman machine ssh -- podman pull ghcr.io/zarcen/bink/bink:latest
podman machine ssh -- podman pull ghcr.io/zarcen/bink/cluster:latest
podman machine ssh -- podman pull ghcr.io/zarcen/bink/dns:latest
podman machine ssh -- podman tag ghcr.io/zarcen/bink/bink:latest    ghcr.io/bootc-dev/bink/bink:latest
podman machine ssh -- podman tag ghcr.io/zarcen/bink/cluster:latest ghcr.io/bootc-dev/bink/cluster:latest
podman machine ssh -- podman tag ghcr.io/zarcen/bink/dns:latest    ghcr.io/bootc-dev/bink/dns:latest

# start cluster locally
bink cluster start --cluster-name test --api-port 0
bink cluster list
Found 1 cluster(s):

  ✓ test (1 node(s), running)
bink node list --cluster-name test
Found 1 cluster node(s):

  ✓ node1 (role: control-plane, status: running, created: 2026-09-15 16:33:43)

Out of scope

ghcr.io/bootc-dev/bink/node (the bootc VM disk image, built in integration-tests.yml's build-node-images job) is not covered here. Turns out getting it to arm64 is bigger than expected: the current bcvk to-disk step hard-requires /dev/kvm, and GitHub-hosted ubuntu-24.04-arm runners don't expose one at all. There's a promising KVM-free path via bootc-image-builder, but that means swapping the actual disk-build tool, a bigger architecture change than fits here. I will track it in a follow-up PR.

Partially addresses #140: covers the bink CLI, cluster, and DNS images

---

Assisted-by: AI
I'm knowledgeable in this problem domain and reviewed the diff and CI run logs carefully. Besides, to ensure the PR quality, several rounds of manually validation and test are conducted

[alicefr]

@zarcen many thanks for the work, the problem is that without the node image we cannot run the tests, and it becomes hard to validate the entire setup.

As far as it regards, the access to kvm. How does it work with emulation? Is it too slow or is this somehow acceptable?