Skip to content

feat(CORE-4981): add multiarch build and merge modes - #159

Open
kaitimmer wants to merge 1 commit into
mainfrom
core-4981-multi-arch-builds
Open

feat(CORE-4981): add multiarch build and merge modes#159
kaitimmer wants to merge 1 commit into
mainfrom
core-4981-multi-arch-builds

Conversation

@kaitimmer

@kaitimmer kaitimmer commented Aug 31, 2026

Copy link
Copy Markdown
Contributor

What changed

New multiarch-mode input with two halves:

  • build — builds the runner's native platform, pushes it by digest only, uploads the digest as an artifact. GitOps, retagging and Upwind are skipped.
  • merge — downloads all digests, combines them into one manifest list, applies the tags, then runs the GitOps/Upwind steps as usual.

Callers wire up the matrix themselves (a composite action cannot create one) — see the new README section. Empty by default, so unchanged callers behave exactly as before.

Also fixes set_output, which could not emit multi-line values: docker-build-platforms / docker-build-outputs now round-trip through GITHUB_OUTPUT, and a multi-line value would have produced an invalid output file.

Why it changed

Our recovery/failover regions have no ARM capacity, so images deployed there must ship both linux/amd64 and linux/arm64. Building natively on one runner per architecture avoids QEMU emulation and cross-compilation entirely.

How to test it

mise run check (110 bats tests + shellcheck). End to end: point a test repo at this branch using the matrix workflow from the README and verify docker buildx imagetools inspect <tag> lists both platforms.


The changes and/or the PR description has generated by with the help of OpenCode.

@kaitimmer
kaitimmer requested review from a team and ricoberger and removed request for a team August 31, 2026 14:51
@kaitimmer
kaitimmer marked this pull request as ready for review August 31, 2026 14:53
@kaitimmer
kaitimmer requested review from a team as code owners August 31, 2026 14:53
@kaitimmer
kaitimmer requested review from 0x46616c6b and soemo August 31, 2026 14:53

@ricoberger ricoberger left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean split into build/merge, and the pass-through design keeps single-arch behaviour untouched. Test coverage on resolve-build-config and merge-manifests is solid. One non-blocking question inline about the merge job getting pinned to amd64 by the architecture check. Worth exercising against a real workflow — e.g. https://github.com/Staffbase/apperator/blob/ee977bc6ccece6030e97360215c5b68513c80efb/.github/workflows/ci-cd.yml#L56. Reviewed at 8c26511.

Comment thread action.yml

- name: Verify Architecture Match
shell: bash
if: steps.preparation.outputs.build == 'true'

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Merge mode still hits this (gated only on build=='true'), and resolve-build-config passes platforms through as the default linux/amd64. So the merge job — which never builds, it just runs imagetools create — is pinned to an amd64 runner or verify-architecture aborts. Intended? If not, worth skipping this + Resolve Build Configuration when multiarch-mode == 'merge'.

@flaxel flaxel left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason to not reuse the docker build target? 👀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants