ci(docker): build and publish multi-architecture images for amd64 and arm64 (#1245) - #1286
Closed
luciusverus-cyber wants to merge 1 commit into
Closed
luciusverus-cyber wants to merge 1 commit into
luciusverus-cyber wants to merge 1 commit into
Conversation
…eejaylaboratory#1245) The repo had no image build workflow at all, so every deployment had to run docker build on the target host. That made images amd64-only by default: a Graviton or ARM Kubernetes node either pulled an emulated image or failed outright, and nothing in the pipeline proved it. Add .github/workflows/docker.yml using QEMU + buildx: - pull requests build backend and dashboard for linux/amd64 and linux/arm64 separately with load:true so the build actually executes, and push nothing, so a fork PR cannot publish to the package registry - main, v* tags and workflow_dispatch publish one manifest list per service tagged with the commit SHA and :latest, using only GITHUB_TOKEN - gha layer cache is shared per service; the runner disk is freed first because emulated arm64 plus npm ci regularly exhausts the 14 GB image - after publishing, imagetools inspect asserts both platforms are in the manifest, so a silently amd64-only manifest cannot go green - path filters include the root and dashboard manifests the dashboard image copies at build time
|
Hey @luciusverus-cyber! 👋 It looks like this PR isn't linked to any issue. If this PR is for one of the issues assigned to you as part of a Wave, please link it to ensure your contribution is tracked properly. You can do this by adding a keyword to the PR description (e.g.,
|
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The repository has no image build workflow at all — every deployment had to run
docker buildon the target host (seedocker-compose.prod.yml, which builds rather than pulls). That makes images amd64-only by default: a Graviton instance or an ARM Kubernetes node pulls an emulated image or fails outright, and nothing in the pipeline proves it.Changes
New
.github/workflows/docker.ymlusing QEMU + buildx:backendanddashboardforlinux/amd64andlinux/arm64separately withload: true, so the build actually executes instead of being deferred to the registry, and push nothing — a fork PR cannot publish to the package registryv*tags / manual dispatch publish one manifest list per service, tagged with the commit SHA and:latest, authenticated withGITHUB_TOKENonlynpm ciregularly exhausts the 14 GB image before the build finishesimagetools inspectasserts both platforms are present in the manifest, so a silently amd64-only manifest cannot report greenVerification
python3 -c "import yaml; yaml.safe_load(...)"on the workflow to confirm it parses, and a structural pass over everyuses:/if:/permissions:block. The two Dockerfiles are the ones already inmain(both multi-stage,node:20-alpine/nginx:1.27-alpine); the dashboard builds from the repo root, which is why its context is.withfile: dashboard/Dockerfile— same asdocker-compose.yml.helm/dockerare not available in this environment, so the build itself was not executed here; the first run on a real runner is the actual test of the QEMU path.Note
This issue is currently closed (batch backlog cleanup on 2026-09-23). The multi-arch gap it describes is still real, so this is offered as a concrete implementation rather than a reopened issue.
Refs #1245