ci: run tests, publish arm64, and gate on deployment - #1
Merged
Conversation
Buildx was already being set up but no platforms list was ever passed, so every published image was amd64-only. That breaks Apple Silicon and ARM runners, which have to fall back to emulation or simply cannot run the image. The Dockerfile now pins the builder to $BUILDPLATFORM and passes TARGETARCH through to the compiler, so the Go build runs natively and cross-compiles rather than emulating the whole toolchain under QEMU. Verified locally: a --platform linux/arm64 build compiles in ~30s and produces a genuine ELF aarch64 static binary in an arm64 image.
This repo proved its image builds and nothing more. A change here that breaks the deployment manifests — a renamed CRD field, a moved route, a changed port — stayed invisible until somebody happened to touch the deploy repo. After pushing an image, call the reusable deployment test in kube-workspaces/deploy: it stands up a kind cluster, installs the CRDs and all four components with this build pinned to the commit under test, and runs the smoke and functional suites. Skipped on pull_request, since nothing is pushed there for the test to pull. The image tag comes from a build-job output rather than being reconstructed in the caller: docker/metadata-action is configured with type=sha,prefix= so the tag is the bare 7-character SHA (confirmed against the tags currently in GHCR), and duplicating that formatting would eventually drift.
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.
Three CI gaps, found while building the deployment test suite in
kube-workspaces/deploy.
1. The test suite never ran
CI ran
go buildandgo vetbut nevergo test, so the tests in this repohave never executed in CI despite predating the workflow. Now run with
-raceplus a coverage summary. Verified passing locally.2. Images were amd64-only
Buildx was already being set up but no
platforms:list was ever passed, soevery published image was amd64-only — broken on Apple Silicon and ARM runners.
The Dockerfile now pins the builder to $BUILDPLATFORM and passes
TARGETARCHthrough to the compiler, so the Go build runs natively and cross-compiles rather
than emulating the whole toolchain under QEMU. Verified locally: a
--platform linux/arm64build compiles in ~30s and produces a genuine ELFaarch64 static binary in an arm64 image.
3. Nothing verified the image actually deploys
This repo proved its image builds and nothing more. A change here that breaks the
deployment manifests — a renamed CRD field, a moved route, a changed port —
stayed invisible until somebody happened to touch the deploy repo.
After pushing an image, CI now calls the reusable deployment test in
kube-workspaces/deploy: it stands up a kind cluster, installs the CRDs and allfour components with this build pinned to the commit under test, then runs the
smoke and functional workspace-lifecycle suites. Skipped on
pull_request, sincenothing is pushed there for it to pull.
The image tag comes from a build-job output rather than being reconstructed in the
caller:
docker/metadata-actionis configured withtype=sha,prefix=so the tagis the bare 7-character SHA (confirmed against the tags currently in GHCR), and
duplicating that formatting would eventually drift.
Note: the deployment-test job will only work once this PR is merged and an image
is pushed — it deliberately does not run on PRs.