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 the fancy-dns-apikey Secret in dns with an
api-key entry. The ingress requests dns.k6n.net TLS from the
letsencrypt-prod ClusterIssuer and cert-manager creates fancy-dns-tls. The
StatefulSet PVCs use the nfs-large StorageClass. 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.