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>

.gitea/workflows/deploy.yaml

@@ -27,6 +27,10 @@ jobs:
       # `kubectl port-forward` — runbook §5. Override with repo variables.
       TALOS_VM_IP: ${{ vars.TALOS_VM_IP }}
       TALOS_HOST: ${{ vars.TALOS_HOST }}
+      # Set it and the stack is published over TLS on <sub>.<domain> by the
+      # in-cluster edge (ADR-0035, runbook §10). Empty = NodePorts, as before.
+      PUBLIC_DOMAIN: ${{ vars.PUBLIC_DOMAIN }}
+      PUBLIC_EMAIL: ${{ vars.PUBLIC_EMAIL }}
     steps:
       - uses: https://github.com/actions/checkout@v4
 
@@ -89,7 +93,13 @@ jobs:
       # The jobs are idempotent, and deleting them first is what keeps a changed
       # Job template from wedging the upgrade (`cannot patch … with kind Job`).
       - name: Deploy the chart
-        run: make k8s-reseed TALOS_HOST=${TALOS_HOST:-localhost} K8S_REGISTRY=${TALOS_VM_IP:-192.168.122.173}:30500
+        run: |
+          set -euo pipefail
+          publish="${PUBLIC_DOMAIN:+--set public.domain=$PUBLIC_DOMAIN --set public.email=${PUBLIC_EMAIL:-}}"
+          make k8s-reseed \
+            TALOS_HOST=${TALOS_HOST:-localhost} \
+            K8S_REGISTRY=${TALOS_VM_IP:-192.168.122.173}:30500 \
+            K8S_SET="$publish"
 
       # `dev` is a mutable tag and helm sees an unchanged pod template, so the
       # new images only land on a restart (pullPolicy is already Always).
@@ -105,6 +115,12 @@ jobs:
       - name: Smoke the public register
         run: curl -fsS --retry 10 --retry-delay 6 --retry-all-errors http://localhost:30141/openbaar/register
 
-      - name: Pods on failure
+      # Cluster-wide, not just `big`: the first thing that can fail is the registry
+      # in its own namespace, and a scheduling problem shows up in the events, not
+      # in `rollout status` — which only ever says "timed out waiting".
+      - name: Pods and events on failure
         if: failure()
-        run: kubectl -n big get pods,jobs || true
+        run: |
+          kubectl get pods -A -o wide || true
+          kubectl -n big get jobs || true
+          kubectl get events -A --sort-by=.lastTimestamp | tail -30 || true

docs/runbooks/kubernetes-talos.md

@@ -366,6 +366,36 @@ immutable, so `helm upgrade` is rejected with `cannot patch "…" with kind Job`
 every time a PR is squash-merged to `main` (and on demand via *Run workflow*). PR CI is the
 merge gate, so the workflow deploys without re-running the checks.
 
+**Prerequisite: the VM must have been installed with the §1 patch.** A stock Talos config
+gives you a node that still carries the control-plane taint and knows nothing about the
+plain-HTTP registry, and the deploy hits those in that order: the `registry` pod sits
+`Pending` until `rollout status` times out, and once that is fixed every repo image fails to
+pull. Two separate fixes:
+
+```bash
+# on the Fedora host — 1. let workloads onto the only node (§1)
+export KUBECONFIG=~/talos-kubeconfig-local
+kubectl taint node --all node-role.kubernetes.io/control-plane-
+
+# 2. trust the in-cluster registry over plain HTTP (§2)
+cat > /tmp/registry-patch.yaml <<'YAML'
+machine:
+  registries:
+    mirrors:
+      "<TALOS_VM_IP>:30500":
+        endpoints:
+          - http://<TALOS_VM_IP>:30500
+YAML
+talosctl -n <TALOS_VM_IP> -e <TALOS_VM_IP> patch mc --patch @/tmp/registry-patch.yaml
+```
+
+Keep those two apart. On Talos 1.14 a patch that also sets
+`cluster.allowSchedulingOnControlPlanes` is rejected with *".cluster.allowSchedulingOnControlPlanes
+is already set in v1alpha1 config"* — the field moved out of the v1alpha1 schema, the same way
+`machine.install` did (§1) — and the rejection takes the whole patch with it, so the mirror
+silently doesn't land either. `kubectl taint` is the documented way (§1); it is undone if the
+node ever re-registers, which is a reboot, not a deploy.
+
 The cluster's API and registry are not exposed publicly, so the job forwards them over the
 same SSH hop the Gitea-runner pipeline uses:
 
@@ -397,6 +427,26 @@ Settings, all on the repository in Gitea:
 The last step smokes `GET /openbaar/register` through the openbaar portal, which exercises
 portal → Caddy → BFF → projection. An empty register passes; a 502 does not.
 
+### Reaching the portals from a laptop
+
+The deployed portals are pinned to `http://localhost:30180` for Keycloak (§5), so a browser
+needs **all five** browser-facing ports on its own localhost — the portal alone is not
+enough, and a missing Keycloak shows up as `ERR_CONNECTION_REFUSED` on
+`/realms/*/.well-known/openid-configuration` followed by an opaque `ERROR Error: [object Object]`.
+`make k8s-portals` does this when kubectl can reach the cluster; through the lab server one
+SSH does it without a kubeconfig at all:
+
+```bash
+ssh -N -p 6667 \
+  -L 30140:<TALOS_VM_IP>:30140 -L 30141:<TALOS_VM_IP>:30141 \
+  -L 30142:<TALOS_VM_IP>:30142 -L 30143:<TALOS_VM_IP>:30143 \
+  -L 30180:<TALOS_VM_IP>:30180 \
+  user@labs.respellion.tech
+```
+
+Then the §5 table's URLs work as written. The admin UIs (OpenZaak, Flowable, …) need no
+forward — they are server-rendered, so the VM's address is fine.
+
 Not covered: the portals still need `make k8s-portals` (or an SSH forward) to be usable in a
 browser, because PKCE needs a secure context (§5). Giving the server a hostname + TLS is the
 upgrade path.