terdut-server/CLAUDE.md

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 docs/development.md (Releasing).

Three things about this repo specifically:

• The image is scanned after it is published, not before. scan-image runs 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 in Ryuvia/charts to 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 — so chart-bump needs --image "$IMAGE" to know which one moves. That sidecar backs up SQLite; the Postgres move (#2) retires it in favour of a postgresql CR with a k8up pg_dump annotation, after which only the app image's tag is left.
• Two demos pin this image, and chart-bump moves neither. terdut-demo in Ryuvia/charts is a TerdutServer CR that terdut-operator reconciles, and its values.yaml image.tag is 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 the terdut-server wrapper, so both drift silently: terdut-demo sat at v0.37.0 through v0.41.0-v0.43.0 until it was synced on 2026-10-08. After a release, bump terdut-demo's tag to the same image-digest and its Chart.yaml version: (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.