ci(WIP): 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?

[zarcen]

@alicefr I think this PR is better to pair with the node image PR I am working on later. The issue is github's arm builder doesn't come with kvm. It is quite slow and I'm thinking if we could use BIB (the bootc-image-builder). I gave it a try and result is good. However, it means to move away from bcvk. I don't know what is the historical reason to pick and use bcvk. I'm still trying if there is a minimal change requirement for it

[alicefr]

@alicefr I think this PR is better to pair with the node image PR I am working on later. The issue is github's arm builder doesn't come with kvm. It is quite slow and I'm thinking if we could use BIB (the bootc-image-builder). I gave it a try and result is good. However, it means to move away from bcvk. I don't know what is the historical reason to pick and use bcvk. I'm still trying if there is a minimal change requirement for it

The main reason for using bcvk was that we can do rootless builds, does BIB run only privileged?

[zarcen]

The main reason for using bcvk was that we can do rootless builds, does BIB run only privileged?

BIB does require full --privileged. Still thinking what is the most non-disruptive way to support the node image in arm

[alicefr]

@zarcen I would open an issue in bootc and tag @cgwalters and @jmarrero they might be able to guide you and for sure we are all interested in supporting arm image builds with rootless. If there is no other way at the moment you could use BIB for ARM

[cgwalters]

So we do have https://github.com/bootc-dev/actions/blob/main/build-push-image/action.yml which would make sense to use...

Hmm we need an agentic review checklist item here for "check to see if the org's actions have this"

[cgwalters]

See bootc-dev/bcvk#73 (and all the other PRs/issues it links to) but I think wrapping it in bcvk would streamline things the most.