Stamp the image version and gate the chart version bumps - #2
Merged
Merged
Conversation
The Docker build context carries no .git, so the Makefile's `git describe` never resolved and every published image reported itself as "dev". The version is now resolved on the runner and handed to the build as an argument. The image tags were assembled by a github-script step that stripped and rejoined the metadata action's output, which produced :latest and :latest-v0.5.0. docker/metadata-action emits them directly instead: master publishes :latest, a release tag publishes :X.Y.Z, :X.Y and :latest. The same scheme is mirrored in build-multiarch.sh, which also never passed the version through. Release notes come from GitHub's own generator rather than a commit dump. scripts/check-version.sh runs on pull requests and on tags. A published chart version is immutable in practice: republishing one overwrites its .tgz and drops the previous release from the repository index entirely. The check refuses a change that did not move the versions it affects, and refuses a tag whose appVersion disagrees with it. Pushes to master and to feature branches are not gated. The .gitpod.yml stub is unused and goes with it.
The version gate requires both to move when the application changes, and appVersion has to name a real release instead of "latest" so it can match the tag that publishes it.
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.
What
Four related fixes around versioning, plus a guard so they cannot regress.
The image never knew its own version
MakefilederivesVERSIONfromgit describe, but the Docker build context only copiesgo.mod main.go Makefile— there is no.gitin the builder stage.git describealways failed and fell back todev, so every image ever published reportedstatic-httpserver dev.The version is now resolved on the runner (
git describe, withfetch-depth: 0) and passed in as a build argument. Verified locally:--build-arg VERSION=v9.9.9-testproducesstatic-httpserver v9.9.9-test; with no argument it falls back todev.The image tags were wrong
A
github-scriptstep stripped and rejoinedmetadata-action's output to build:latest-${result}, giving tags likelatest-v0.5.0andlatest-master. It also referenced a step ID (steps.set-result) that does not exist.docker/metadata-actionnow emits the tags directly:-versionmaster:latestv0.5.0-3-gabc1234v0.5.0:0.5.0,:0.5,:latestv0.5.0:pr-N(built, not pushed)v0.5.0-3-gabc1234build-multiarch.shis brought in line: it never passed the version through either, and hardcodedVERSION="latest"as both the tag and the version.Release notes
changelog: use: github-native— GitHub's merged-PR list instead of a flat commit dump. Thesort/filtersblock is removed because github-native ignores it.A version gate
scripts/check-version.sh, run on pull requests and on tags only — master and feature branches are not gated.A published chart version is immutable in practice. Republishing one overwrites its
.tgzand the previous release disappears from the repo index entirely. Measured against a real Helm 4.3.0 repo: same chart version, newappVersion, and the digest changes under an unchanged version number, leaving exactly one entry with no rollback target.versionappVersion.github/)helm/**only (excl.Chart.yaml)main.go,go.mod,Makefile,Dockerfile,html/)An app change requires a chart bump because
appVersionlives insideChart.yamland the chart is republished on every merge to master — bumpingappVersionalone emits a new.tgzat an unchanged chart version.On a tag:
appVersionmust equal the tag (v0.6.0→0.6.0), and the chart version must differ from the previous tag's.Chart.yamlis excluded from "the chart changed" detection, otherwise bumpingappVersionwould demand a chart bump for that edit alone.The
ifsits on the step, not the job: a skipped job also skips everything thatneedsit, which would take the whole build down on every master push.Expected to fail
This PR trips its own gate.
DockerfileandMakefileare app files, andChart.yamlstill readsversion: 0.3.0/appVersion: "latest". That needs a decision —appVersion: "latest"can never match a release tag, and becausedeployment.yamluses.Chart.AppVersionas the image tag default, changing it also changes which image the chart pulls.Also
.gitpod.ymlwas an unused stub (echo 'TODO: build project').🤖 Generated with Claude Code