Add ARM64 (linux/arm64) multi-architecture Docker image support

[sandhyaguduru]

Summary

• Re-enable ARM64 support using Docker Buildx and QEMU in the GitHub Actions CI pipeline
• Build workflow now produces a multi-arch manifest covering linux/amd64 and linux/arm64
• Release workflow uses docker buildx imagetools create to promote the full multi-arch manifest to Docker Hub, replacing the single-platform docker tag/docker push approach

Context

ARM64 support was previously added (Sept 2023) but removed in April 2024 (SCANCLI-141) when CI was on Cirrus CI. Since then, CI has migrated to GitHub Actions, and both base images (alpine:3.19 and amazoncorretto:21-al2023) already support ARM64 natively. The SonarScanner CLI binary (8.0.1.6346) is Java-based and platform-independent, with native ARM64 support in the current stable release.

Users running on AWS Graviton (ARM64) Jenkins nodes or other ARM64 infrastructure currently cannot use the official Docker image — it crashes with exec format error.

Why this works without Dockerfile changes

• Base images: alpine:3.19 and amazoncorretto:21-al2023 both publish linux/arm64 variants
• Scanner CLI 8.0.1.6346: The latest stable release — Java-based and platform-independent with native ARM64 support. No architecture-specific binaries involved
• Entrypoint: Shell script, architecture-agnostic

Changes

.github/workflows/build.yml

• Added docker/setup-qemu-action for cross-platform emulation
• Added docker/setup-buildx-action for buildx builder
• Changed docker build to docker buildx build --platform linux/amd64,linux/arm64

.github/workflows/release.yml

• Added docker/setup-buildx-action for buildx builder
• Replaced docker tag + docker push with docker buildx imagetools create to copy the entire multi-arch manifest to Docker Hub
• Used docker/login-action for registry authentication (consistent with build workflow)

Test plan

• CI build produces a multi-arch manifest with both linux/amd64 and linux/arm64
• Existing BATS integration tests pass (amd64 variant pulled automatically on amd64 runner)
• docker manifest inspect shows both architectures in the image index
• Release workflow successfully promotes multi-arch manifest to Docker Hub

🤖 Generated with Claude Code

[sonar-review-alpha]

Summary

This PR enables multi-architecture Docker builds for linux/amd64 and linux/arm64 using Docker Buildx and QEMU. The build workflow now produces a multi-arch image manifest, while the release workflow uses docker buildx imagetools create to promote that entire manifest to Docker Hub tags — replacing the previous single-platform docker tag/docker push approach. This allows users on ARM64 infrastructure (AWS Graviton, etc.) to pull the official image without emulation or crashes.

What reviewers should know

Key changes in build.yml:

• Added QEMU and Buildx setup steps (enables cross-platform building on standard runners)
• Changed docker build to docker buildx build --platform linux/amd64,linux/arm64

Key changes in release.yml:

• Replaced inline docker login commands with docker/login-action for both Repox and Docker Hub (cleaner, more secure)
• Replaced docker tag + docker push with docker buildx imagetools create — this copies the pre-built multi-arch manifest from Repox to Docker Hub without rebuilding, avoiding bandwidth and time waste

Important detail: The release step does NOT rebuild the image. It assumes the multi-arch manifest is already staged in Repox from the build workflow, then uses imagetools create to create new tags pointing to those same architecture-specific layers.

Testing context: Existing BATS integration tests remain unchanged and will run on amd64 runners, pulling the amd64 variant automatically. The multi-arch manifest structure is transparent at pull time.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

Clean implementation with no issues found. The cross-registry imagetools create promotion (Repox → Docker Hub) is the correct approach — it copies manifests and blobs across registries, so both the Repox login (stored earlier in the job) and the Docker Hub login (stored immediately before the push step) are active simultaneously in the credential store, which is exactly what imagetools create needs. Credential ordering is correct in both workflows.

🗣️ Give feedback