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.
60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
## 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:
|
|
|
|
```sh
|
|
~/.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-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.
|