Root cause of the git-sync failure: the cron pod only ran git pull/push
against /data/myorg but never ensured the repo existed, and the GIT_REPO_URL
secret historically pointed at the wrong Gitea subdomain (gitea.rogi.casa),
which 526s through Cloudflare -> 'Not a git repository: /data/myorg'.
Fixes:
1. Add an idempotent git-clone initContainer (guarded by [ ! -d /data/myorg/.git ])
so the cron job self-heals and actually clones on first run.
2. Normalize GIT_REPO_URL host to git.rogi.casa at runtime (sed), so the clone
works even if the cluster secret still contains the stale gitea.rogi.casa host.
The working subdomain is git.rogi.casa.
Evidence (Loki, last 24h+):
{namespace="myorg-assistant",pod=~"myorg-git-sync.+"}
-> Pull/Push: Error: Not a git repository: /data/myorg (every run)
-> job swallowed error, exited 0, so looked successful
Risk: low. initContainer mirrors the Deployment's; host-normalization is
idempotent. No RBAC/CRD/ArgoCD/volume changes.
CronJob pods were stuck in ImagePullBackOff because they referenced
the local-only image 'myorg-assistant:latest' which is not present
on the node. Switch all 5 cronjobs to the Gitea registry image
git.rogi.casa/roger/myorg-assistant/myorg-assistant:fcf79bf
(matching the Deployment), set imagePullPolicy: Always, and add
imagePullSecrets: gitea-registry so they can authenticate to the
private registry.
The ingresses referenced a Cloudflare OriginIssuer 'prod-issuer' whose CRD
and controller are not installed in the cluster, so cert-manager could not
issue certs and Traefik served a default cert (invalid SSL). Switch to the
existing letsencrypt-prod ClusterIssuer with specific hostnames + per-app
secrets, matching the working ingresses (http-01 cannot issue wildcards).
