I had built a parallel mechanism for this repo rather than copying the
workflow that is already known to work on this cluster. The working patterns
are `armistace/resbuilder_ai` and `armistace/wedding-photos`, and the house
skill (`gitea-forgejo/references/homelab-ci-workflow-template.md`) documents
them. This rewrites the workflow to match them.
What changed, and why each piece was wrong:
- ONE job, not three. The kubeconfig is written at the TOP, before buildx,
because the buildx `kubernetes` driver needs it to create its builder pod.
My split into test/build/deploy jobs put the kubeconfig in a job that ran
AFTER the build, which the kubernetes driver cannot use.
- `driver: kubernetes` with `namespace=gitea-runner`, not the `remote`
driver. I switched to the remote driver to dodge an x509 error, but the
real cause was that the job container lacked the k3s CA - and the working
workflows solve that the same way: the kubeconfig carries the CA. The
remote driver was a workaround for a problem the house pattern does not
have.
- The CA-refresh script and the pinned-fingerprint file are deleted. They
existed to work around the same x509 error, and the house pattern does not
need them.
- The deploy step installs kubectl and applies `kube/*.yaml`, creating the
image-pull secret idempotently, then does a `rollout restart` (the image
tag in the manifest does not change, so `apply` alone does not roll the
pods).
- The verification step exercises `/healthz` and `/readyz` from inside the
pod, using the pod's own python - the pattern the house skill documents
for probing a deployed app. There is no `curl` in the slim image.
The Deployment manifest also changes:
- `runAsUser: 999` at the POD level, matching the `beer` user in the image.
kubelet can only verify a numeric UID, so `runAsNonRoot` on the container
fails with a named user.
- `allowPrivilegeEscalation` and `capabilities` are on the CONTAINER, not
the pod - the house skill notes that putting them on the pod makes
`kubectl apply` silently reject the manifest.
- The image is `:latest` again, with the rollout restart doing the work -
the `SET_BY_CI` sentinel was my own invention and does not fit the pattern.
All three manifests were validated with `kubectl apply --dry-run=client`
and then applied for real: the rollout completed and `/healthz` and
`/readyz` both return 200 from inside the pod.
The cluster-count guard I added used `grep -c '"name"'`, which counts
LINES. The jsonpath output is a single line, so the count was 1 for a
kubeconfig with clusters and 1 for one without - which made the guard
reject every kubeconfig:
ERROR: the kubeconfig has no cluster entries.
The count is now done with `grep -o . | wc -l`, which counts occurrences
rather than lines. Tested against both cases:
- a real kubeconfig with a stale CA -> the CA is refreshed and kubectl works
- a kubeconfig with no clusters -> refuses with a clear message
hermes