Problem
The published ghcr.io/tuna-os/corral:latest image is currently amd64-only even though Corral's rolling CLI binaries and marketplace plugins already support both amd64 and arm64.
The container workflow hard-codes GOARCH=amd64 and downloads amd64-only kubectl and virtctl binaries before using a single-platform Docker build. This prevents the in-cluster web UI from running natively on arm64 Kubernetes nodes. The image publication job is skipped on pull requests, so architecture regressions are not caught before merge.
Proposed change
- Prepare Corral,
kubectl, and virtctl artifacts for both amd64 and arm64.
- Select the matching artifacts with BuildKit's target architecture.
- Build and publish one multi-platform image containing
linux/amd64 and linux/arm64 manifests.
- Build both platforms on pull requests without publishing them.
Acceptance criteria
- The container build succeeds for both
linux/amd64 and linux/arm64.
- Each platform contains architecture-matching Corral,
kubectl, and virtctl binaries.
- Main-branch publication preserves the existing
latest and short-SHA tags.
- Pull requests validate both container platforms without requiring package write access.
Problem
The published
ghcr.io/tuna-os/corral:latestimage is currently amd64-only even though Corral's rolling CLI binaries and marketplace plugins already support both amd64 and arm64.The container workflow hard-codes
GOARCH=amd64and downloads amd64-onlykubectlandvirtctlbinaries before using a single-platform Docker build. This prevents the in-cluster web UI from running natively on arm64 Kubernetes nodes. The image publication job is skipped on pull requests, so architecture regressions are not caught before merge.Proposed change
kubectl, andvirtctlartifacts for both amd64 and arm64.linux/amd64andlinux/arm64manifests.Acceptance criteria
linux/amd64andlinux/arm64.kubectl, andvirtctlbinaries.latestand short-SHA tags.