3 Commits

Include renames

Author	SHA1	Message	Date
notandClaude Opus 5	dfa1a370ac	ci(deploy): publish the stack over TLS when PUBLIC_DOMAIN is set (refs #175) ... The in-cluster edge (#178) is off unless the chart is given a domain, so pass one through from a repository variable. Unset, the deploy is exactly what it was — NodePorts, and the portals reachable only over the SSH forwards. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 16:31:47 +02:00
notandClaude Opus 5	d17e79959b	ci(deploy): say why a deploy stalled, and document the cluster prerequisite (refs #175) ... The first run against the lab server's VM timed out on `kubectl rollout status` for the in-cluster registry with nothing but "timed out waiting for the condition". The cause was three commands up the runbook: that VM was installed from a stock Talos config, so the only node still carries the control-plane taint and no pod can schedule — and the missing registry mirror would have failed the image pulls right after. `rollout status` can only ever report the symptom, so dump the whole cluster's pods and the recent events on failure instead of `big`'s pods alone; the scheduler's "untolerated taint" message is the answer and it lives in the events. Runbook §9 now opens with the machine-config patch the deploy assumes, as one applied-live patch rather than a `kubectl taint` that the controller undoes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-18 16:01:47 +02:00
notandClaude Opus 5	fc036d53d5	ci(deploy): deploy the stack to Talos on merge to main (refs #175) ... 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