Niklas Ye
1cb09525e3
terdut-demo in Ryuvia/charts, a TerdutServer CR reconciled by terdut-operator, and the kind demo in terdut-operator both pin this image, and chart-bump only moves the terdut-server wrapper. terdut-demo therefore sat at v0.37.0 through v0.41.0-v0.43.0 before it was synced on 2026-10-08, and nothing said it was behind. CLAUDE.md now lists the step after the release one: bump the demo's tag to the same digest and its chart version, as its own PR, and read the range's migrations first, since the demo's database migrates forward at start. Documentation only: nothing is built from this file, so it needs no release.
3.5 KiB
Release
Say "Release" (or "Release X.Y.Z") and the release skill runs it: commit, push, tag,
wait for the pipeline, then open the wrapper-chart PR against Ryuvia/charts. It stops
there — merging and the Flux reconcile stay manual, deliberately.
Preconditions and the plan, without side effects:
~/.claude/skills/release/scripts/release-preflight # state + suggested version
~/.claude/skills/release/scripts/release-preflight vX.Y.Z # validate that release
Config is .release.conf here plus make release-vars. The process itself lives in
~/.claude/skills/release/; why it is shaped this way is in README.md §Releasing.
Three things about this repo specifically:
- The image is scanned after it is published, not before.
scan-imageruns trivy against the pushed image, because trivy cannot read a locally built one on this runner. A red scan therefore unpublishes nothing — it means: do not bump the wrapper chart inRyuvia/chartsto this version. Added 2026-09-02; every release up to and including v0.9.3 was published with no CVE check at all. - The wrapper chart has two
tag:lines — the app image and the python backup sidecar — sochart-bumpneeds--image "$IMAGE"to know which one moves. That sidecar backs up SQLite; the Postgres move (#2) retires it in favour of apostgresqlCR with a k8uppg_dumpannotation, after which only the app image's tag is left. - Two demos pin this image, and
chart-bumpmoves neither.terdut-demoinRyuvia/chartsis aTerdutServerCR that terdut-operator reconciles, and itsvalues.yamlimage.tagis meant to match production's pin (same digest). The kind demo in terdut-operator (examples/demo/01-server.yaml) pins a tag too. A release only bumps theterdut-serverwrapper, so both drift silently:terdut-demosat at v0.37.0 through v0.41.0-v0.43.0 until it was synced on 2026-10-08. After a release, bumpterdut-demo's tag to the sameimage-digestand itsChart.yamlversion:(Flux reconciles on ChartVersion), as its own PR, and say in the release report whether you did. Neither demo has anything but the pin to change, but read the version range's migrations first: the demo's Postgres migrates forward at startup.
Checks
The tests need a Postgres: make test-db starts one and prints the DSN, make test-db-stop
removes it, and TERDUT_TEST_DSN is how both the Makefile and ci.yaml's service container
point the suite at it. Without it the suite fails rather than skipping, on purpose.
make fmt lint test helm-lint is what the pipeline runs — ci.yaml and release.yaml
call these targets rather than restating them, the way riksdata and rd-web do. A green gate
here and a green pipeline are the same code, not two descriptions of it. test adds -race,
which the workflows do not have to ask for since they call the target; see the comment on it
for why.
make release (build + push the multi-arch image, package + push the chart) is what
release.yaml invokes. Do not run it by hand — it refuses VERSION=dev for that reason, and
publishing happens by pushing a tag.
Three scans, and they see different things: security-go (govulncheck) reads the source and
its module graph and reports only vulnerabilities the code can actually reach;
security-secrets (gitleaks) reads the working tree, not the history, so it catches a secret
on the way in rather than auditing what is already committed; security-image (trivy) reads
the published artifact and therefore only runs on a tag. The first two gate every push.