The deploy job only waited on the deployments that existed when it was
written, so a broken rollout of either new app would have been reported
as a successful deploy.
Also records the two new secrets in the bootstrap table, and the two
traps found while adding these: dashwise publishes :latest for amd64
only, and a server-side dry run of a brand new namespace reports every
resource inside it as missing until the namespace exists.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An unset secret expands to empty, base64 -d writes a zero-byte kubeconfig,
and kubectl falls back to localhost:8080 with a misleading connection
error. Guard both jobs and echo the current context after configuring.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- .gitea/workflows/deploy.yaml: PRs run a server-side dry-run; pushes to
main apply the kustomization and wait for all rollouts. Modeled on
socktop-webterm's pipeline; uses the same KUBECONFIG secret convention
and gitea-deployer ServiceAccount.
- rbac/gitea-deployer.yaml: ClusterRole/Binding (admin bootstrap, outside
the root kustomization) — repo resource kinds only, no secrets access,
no delete verbs, no RBAC escalation. Applied to the cluster 2026-07-26.
- One-time env->secretKeyRef migration executed against the cluster;
README updated.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
jasonwitty