ci: native multi-arch builds on ebpro-org/ebpro-org-arm (no QEMU)

[emmanuelbruno]

Replaces the jib cross-platform build (the arm64 leg was emulated on the x64 runner and made runs slow enough to be cancelled). The matrix builds each arch natively on its dedicated ARC scale set (amd64 -> ebpro-org, arm64 -> ebpro-org-arm), so tests run on both architectures. The multi-arch manifest list is assembled registry-side with docker buildx imagetools (no QEMU/binfmt anywhere). Scale sets deployed via the gitops repo (commit cab05e9).

PR run exercises the full chain (amd64 leg on ebpro-org, arm64 leg on ebpro-org-arm cold-start, manifest on ebpro-org). Note: the arm node is a dev VM — if it is down, the arm leg will queue without error (self-hosted labels have no GHA timeout).

[Copilot]

🟡 Changes recommended

The workflow currently has invalid YAML in the steps: blocks (sequence indentation), which will prevent GitHub Actions from parsing/running the CI.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the GitHub Actions CI workflow to build amd64 and arm64 images natively on dedicated self-hosted ARC scale sets (removing the previous cross-arch/emulation approach), then publishes a multi-arch manifest list in the registry using docker buildx imagetools.

Changes:

• Convert the build job into a per-arch matrix running on ebpro-org (amd64) and ebpro-org-arm (arm64), tagging arch-specific images.
• Add a manifest job that assembles and verifies the multi-arch manifest list from the two arch-specific images.
• Add job timeouts and clarify intent with workflow comments.

File summaries

File	Description
.github/workflows/ci.yml	Switch to native per-arch matrix builds and add a registry-side manifest assembly job.

Review details

Suppressed comments (2)

.github/workflows/ci.yml:47

• Continuation of the YAML indentation issue in the build job: the remaining steps (DockerHub login + image build) must also be indented under steps:. While touching this block, you can avoid re-running tests by using -DskipTests (since the earlier verify step already ran them) and drop clean to reuse the existing build outputs.

    - name: Login to DockerHub
      uses: docker/login-action@v3
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}
        password: ${{ secrets.DOCKERHUB_TOKEN }}
    - name: Build and Push Image (native ${{ matrix.arch }})

.github/workflows/ci.yml:68

• The manifest job has the same YAML issue as build: the steps: list items are not indented beneath steps:. Also, docker buildx imagetools depends on the Buildx plugin being available on the self-hosted runner; adding an explicit Buildx setup step makes this job more reliable. Finally, tagging/publishing :latest on pull_request runs can overwrite the canonical latest; consider restricting latest to pushes to main.

    steps:
    - name: Login to DockerHub
      uses: docker/login-action@v3
      with:
        username: ${{ secrets.DOCKERHUB_USERNAME }}

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.