Two workflows published the chart and disagreed about its metadata.
release.yml stamps version and appVersion from the git tag;
chart-release.yml, triggered by any charts/** push to main, took
Chart.yaml verbatim, where appVersion is the hardcoded "latest".
Both fired for the same commit, both tried to publish the same chart
version, and skip_existing turned whichever lost into a no-op — so what
a release said about itself came down to which runner was quicker.
Chart 0.9.0 went out that way, reading appVersion "latest". Every
earlier release got the right answer by accident: Chart.yaml's version
lagged the published set, so chart-release.yml always collided with an
existing version and skipped, leaving release.yml to win uncontested.
Bumping Chart.yaml to match the tag before cutting 0.9.0 removed that
accident and the race showed itself.
Making the two agree is not possible. The tag is pushed after the branch,
so a workflow triggered by the main push cannot know the version it is
about to be tagged with — no amount of deriving from git describe fixes
that ordering. The fix is one publisher, triggered by the tag, so
chart-release.yml is deleted.
The chart now only ships with an app release. Nothing is lost: the sed in
release.yml ties the chart version to the app version, so a chart-only
change never had a version of its own to be released under. Chart fixes
ride the next tag.
Chart.yaml's version and appVersion are documented as the placeholders
they now are, so the next person does not helpfully bump them and
reintroduce this. skip_existing stays, for idempotent re-runs of a failed
release rather than for the race, and a non-version tag now fails the job
instead of silently publishing unstamped metadata.
The release workflow gates a tag, which is the last possible moment: a
commit that breaks the suite stayed green on main until somebody decided
to publish, and then failed the release instead of the change that
caused it.
A CI workflow now runs go vet and go test on pushes to main and on pull
requests.
push is scoped to main rather than left open. A branch pushed as part of
a pull request would otherwise be checked twice, and gh-pages carries the
published chart index with no Go code in it, so go vet there would fail
on a missing go.mod.
Runs for the same ref cancel each other, since a rapid series of pushes
only needs the last one checked.
CI only ever built and published. The 44 tests in internal/api ran on a
laptop or not at all, so a tag could publish binaries, a container image
and a Helm chart from a commit whose tests had never been run — and the
tests are the only thing holding several documented contracts in place,
including the received_at heartbeat and the alert ordering guard.
A test job now runs go vet and go test, and build, docker and chart all
depend on it. The release job is downstream of build, so a tag that fails
publishes nothing at all rather than publishing three artifacts out of
four.
chart-release.yml is deliberately left alone. It fires on charts/**
pushes and publishes the chart, which contains no Go code and only
references an image tag rather than building one, so gating it on the Go
suite would add a minute to every chart edit for no signal.
This still only runs at release time; nothing checks a push or a pull
request, so a broken commit stays green until somebody tags it.
chart-release.yml fires on any charts/** push to main and ran
chart-releaser against the committed Chart.yaml version, failing with
422 already_exists whenever that version was already published. A tagged
release also publishes the chart from release.yml, which seds the
version from the tag, so the two workflows raced and this one lost.
Brings it to parity with the chart job in release.yml, which has carried
skip_existing since 1451682.
Tag-triggered workflow builds multi-platform binaries, pushes a multi-arch
Docker image to GHCR, bumps and releases the Helm chart, and creates a
GitHub release with all binary artifacts. Adds GPL-3.0 LICENSE and version
variable stamped at build time via ldflags.
charts/terdut-server/ — Helm chart for Kubernetes deployment:
- Deployment (replicas=1, /healthz probes, TERDUT_DB_PATH=/data/terdut.db)
- Service (ClusterIP :8080)
- PVC (1Gi, synology-iscsi) mounted at /data
- HTTPRoute via envoy-main gateway
.github/workflows/chart-release.yml — packages and publishes the chart to
gh-pages branch on any push to main that touches charts/; repo URL will be
https://yeniklas.github.io/terdut-server once the repo is made public
Niklas Ye