Add multi-architecture support for Docker images and workflows

[stearz]

What type of PR is this?

/kind feature

What this PR does / why we need it:

adds support for arm64

Which issue(s) this PR is related to:

Fixes #840

Special notes for your reviewer:

none

Does this PR introduce a user-facing change?

yes, containers now also run on arm64 machines

Added support for arm64

---

Summary by cubic

Add multi-architecture Docker builds (linux/amd64, linux/arm64) and update release workflows to push per-arch images and create multi-arch manifests, so images run on arm64 too (Fixes #840).
Makefile adds IMAGE_PLATFORMS, PUSH, and a manifest target; Dockerfiles now copy arch-specific binaries using TARGETARCH, and tag releases publish a latest multi-arch manifest.

^{Written for commit e6d86de. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 9 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="Makefile">

<violation number="1" location="Makefile:108">
P2: `image-multiarch` hardcodes prebuilt arches (`amd64 arm64`) while `--platform` uses configurable `IMAGE_PLATFORMS`, which can produce missing per-arch binaries when platforms are overridden.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[gjkim42]

This is a duplicate of #787

[stearz]

It would be cool if ypu merge one of them. 😉

[stearz]

Hopefully 6bd4892 addresses the requested changes

[gjkim42]

will review it this weekend.

[gjkim42]

P1: On tag pushes, the matrix build publishes ${VERSION}-amd64 and ${VERSION}-arm64, but this step assembles :latest from latest-amd64 and latest-arm64. Those source tags are never built in this workflow run, so a fresh release can fail here or repoint :latest at stale per-arch images from an older run. Please build and push latest-$arch before this step, or assemble latest from the versioned arch tags created above.

[stearz]

fixed in e6d86de

[gjkim42]

P1: Removing cmd/ghproxy and cmd/kelos-webhook-server from the default IMAGE_DIRS breaks existing callers of make image. The e2e workflow still runs make image VERSION=e2e and then loads ghcr.io/kelos-dev/ghproxy:e2e, so CI will fail because that tag is no longer built. It also stops publishing versioned kelos-webhook-server images even though the chart still references that image when the webhook server is enabled.

[stearz]

oops, forgot to get changes from upstream. Fixed in e6d86de

[gjkim42]

Cleanup: after this refactor the release flow uses make image ... PUSH=true plus make manifest, and I could not find any remaining in-tree callers of make push. Keeping the old target around leaves a dead interface in the Makefile, so please remove push in the same cleanup.

[stearz]

cleaned up in e6d86de

[gjkim42]

The SOURCE_VERSION fix and make push removal look good. One build-breaking issue remains with the Dockerfiles that weren't updated.

[gjkim42]

Bug: cmd/ghproxy and cmd/kelos-webhook-server are back in IMAGE_DIRS, but their Dockerfiles weren't updated for multi-arch. The image build loop (line 89) renames binaries to bin/$name-linux-$arch, so bin/ghproxy no longer exists — only bin/ghproxy-linux-amd64. Their Dockerfiles still COPY bin/ghproxy . and COPY bin/kelos-webhook-server ., which will fail.

Needs the same ARG TARGETARCH + renamed COPY treatment as the other Dockerfiles:

ARG TARGETARCH
COPY bin/ghproxy-linux-${TARGETARCH} ghproxy

[gjkim42]

Nit: cmd/kelos-token-refresher matches cmd/% here, so it gets pre-built and renamed to bin/kelos-token-refresher-linux-$arch. But its Dockerfile is a multi-stage build that rebuilds from source inside Docker — these pre-built binaries are never used. Not a correctness issue (the Docker build still works), but it wastes CI time. Consider either updating its Dockerfile to match the others, or excluding it from this loop.