feat(ci): publish the Tracker's images to GHCR — GT-435 - #113
Merged
Conversation
Until today this repository shipped three Dockerfiles and ZERO image CD. No workflow built or pushed them, while the charts referenced evolith-tracker-api:0.0.1, evolith-tracker-web:0.0.1 and evolith-tracker-gateway:local - the last a tag no registry can ever serve. The deployment path was not untested, it was not wired: every chart pointed at an image nothing produced, and no green CI could have shown it because nothing had ever pulled them. images.yml builds and pushes all three to GHCR on every merge to main and develop, :latest plus :<sha>, authenticating with the built-in GITHUB_TOKEN so it works from the first run with no new secret. fail-fast is off on purpose: a partial publish is a deployment where some services are new and some are not, and that is worth seeing whole. The workflow does not trust its own green tick. After pushing it runs `docker buildx imagetools inspect` on the sha tag, because a push step exiting zero is not proof the image is pullable - and that gap between "the job was green" and "the artifact is there" is exactly what let three charts point at nothing. Verified before wiring any of it: all three images were built locally from the documented `src/` context and all three succeed. A CD that publishes a broken image is worse than none. check-deployable-images.mjs is ported from the Core and runs in CI. It found a defect IN ITSELF here, through a negative test rather than the happy path: it read `evolith-tracker-api:0.0.1` out of a COMMENT in the new workflow - the comment that documents the broken reference - and blessed the very tag the comment exists to warn about. Comments are now stripped before scanning, in both repositories. Charts now point at latest, with the reasoning in the values files including why production must still override it with --set image.tag=<sha>: latest cannot be rolled back, and GT-448 requires a rollback that has actually been exercised.
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
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.
Until today this repository shipped three Dockerfiles and zero image CD. No workflow built or pushed them, while the charts referenced:
evolith-tracker-apighcr.io/…:0.0.1evolith-tracker-webghcr.io/…:0.0.1evolith-tracker-gatewayevolith-tracker-gateway:localThe deployment path was not untested — it was not wired. Every chart pointed at an image nothing produced, and no green CI could have shown it, because nothing had ever pulled them. Found while preflighting
GT-435from the Core repository, without a cluster.What ships
images.ymlbuilds and pushes all three to GHCR on every merge tomainanddevelop—:latestplus:<sha>— authenticating with the built-inGITHUB_TOKEN, so it works from the first run with no new secret.fail-fast: falseon purpose: a partial publish is a deployment where some services are new and some are not, and that is worth seeing whole.The workflow does not trust its own green tick. After pushing it runs
docker buildx imagetools inspecton the sha tag. A push step exiting zero is not proof the image is pullable, and that gap between "the job was green" and "the artifact is there" is exactly what let three charts point at nothing.Verified before wiring any of it
All three images were built locally from the documented
src/context, and all three succeed:A CD that publishes a broken image is worse than none.
The guard found a defect in itself
check-deployable-images.mjsis ported from the Core and now runs in CI. Its negative test — not the happy path — caught it readingevolith-tracker-api:0.0.1out of a comment in the new workflow: the comment that documents the broken reference. It was about to bless the very tag the comment exists to warn about.Comments are now stripped before scanning, in both repositories.
Verified failing on all three defect classes here: a tag no workflow publishes, a
:localtag, and a semver with no git tag behind it.Charts
Now
latest, with the reasoning in each values file — including why production must still override it with--set image.tag=<sha>:latestcannot be rolled back, andGT-448requires a rollback that has actually been exercised.🤖 Generated with Claude Code