Niklas Ye
44b2eb2cc3
The README was 1,240 lines of reference material and still described a SQLite quick start. It is now a short tour (highlights, screenshots of the web UI, an accurate quick start against Postgres), and each topic has its own page under docs/ with an index: deployment, configuration, Alertmanager, incidents, notifications, escalation, dead man's switches, single sign-on, web UI, API and development. SERVICE-ACCOUNTS.md is rewritten from a proposal into a reference, and TEAM-LOOKUP.md is gone with the endpoint it described. The "Upgrading to ..." sections for an unreleased product are dropped. Claude-Session: https://claude.ai/code/session_016mBLURvJoMuUEr9cB2RpUN
60 lines
3.6 KiB
Markdown
60 lines
3.6 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 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.
|