Deploying fancy-dns with k8s-helper
Gitea Actions builds and pushes fancydns/fancy-dns:<commit> and
fancydns/fancy-dns:latest on pushes to main. It then sends a signed
reconcile webhook so the agent applies the published image from ./deploy/k8s
into namespace dns.
One-time setup
The k8s-helper GitOps CRDs and agent must be installed, and its dashboard must
have K8SHELPER_GITOPS_WEBHOOK_SECRET configured. The GitSource reuses the
existing dev/gitea-k8s-helper Secret; its token must have read access to this
repository. The Gitea Actions secret GITOPS_WEBHOOK_SECRET must contain the
same webhook key. A user- or organization-level Actions secret can be shared
with other repos.
Configure this repository's Gitea webhook for push events only:
- Target:
https://ui.k6n.net/api/gitops/webhooks/gitea - Secret: the same value as
K8SHELPER_GITOPS_WEBHOOK_SECRET
Bootstrap the GitOps resources once with kubectl apply -f gitops/. The
dns namespace is declared in the managed kustomization. Before bootstrapping,
create fancy-dns-apikey in dns as described in deploy/k8s/08-secret-apikey.yaml
and ensure the cert-manager-managed fancy-dns-tls Secret exists. The GitOps
kustomization intentionally excludes both example Secret manifests so it never
replaces real credentials or TLS material with placeholders.
The runner uses its existing Docker login. Each successful main build sends a
signed webhook after pushing, which avoids reconciling before the new image is
available. prune is initially disabled; inspect the inventory before enabling
it.