register-referentie

The chart has been deployable by hand since #25 and linted in CI since #168;
this makes a merged PR actually ship it to the lab server's Talos VM.

Neither the Kubernetes API nor the in-cluster registry is publicly reachable,
so the job forwards 6443, 30500 and 30141 over the same SSH hop into the Fedora
host that the Gitea-runner pipeline uses. That splits the registry into two
names for one store: images are pushed through the tunnel to localhost:30500,
and the node pulls them from its own NodePort — the address its registry-mirror
patch trusts over plain HTTP.

It deploys with `make k8s-reseed` rather than `make k8s-up`: the bootstrap Jobs
are idempotent, and deleting them first is what stops a changed Job template
from wedging `helm upgrade`. The nine deployments are then rolled explicitly,
because `dev` is a mutable tag and helm sees an unchanged pod template.

PR CI is the merge gate, so this workflow does not re-run the checks. Deploys
queue instead of cancelling: a `helm upgrade` killed half-way leaves the release
in `pending-upgrade` and needs unwedging by hand.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-18 15:40:42 +02:00

architecture

ci(k8s): gate the Helm chart in CI + a compose↔chart drift check (closes #168 ) (#171 )

2026-09-18 13:25:24 +00:00

runbooks

ci(deploy): deploy the stack to Talos on merge to main (refs #175 )

2026-09-18 15:40:42 +02:00

demo-script.md

S-24/#25 · Helm chart + Kubernetes deployment, and Caddy for the portals (#166 ) (#167 )

2026-09-10 08:53:58 +00:00

frontend-decisions.md

S-24/#25 · Helm chart + Kubernetes deployment, and Caddy for the portals (#166 ) (#167 )