notandClaude Opus 5
fc036d53d5
CI / k8s (pull_request) Successful in 5s
CI / lint (pull_request) Successful in 1m25s
CI / build (pull_request) Successful in 1m22s
CI / unit (pull_request) Successful in 1m24s
CI / frontend (pull_request) Successful in 1m45s
CI / mutation (pull_request) Successful in 3m1s
CI / verify-stack (pull_request) Successful in 6m22s
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>