registry_prune.py sorted candidate tags by the manifest GET response's
Date header - which is just "now", the moment the prune script made
that request - not when the image was actually built. Every tag it
queries in the same prune run lands within the same second, so the
"sort by age" was effectively random. On run #56 this deleted the tag
this same CI run had just pushed (4efe848, digest 60114dea) seconds
after pushing it, and seconds before the gitops step committed a
deployment pointing at that now-deleted digest - the cluster then
sat in ImagePullBackOff since the referenced image no longer existed.
Now reads the real "created" timestamp from the image's config blob
(resolving through a manifest list/index if the tag is multi-platform),
and always protects the current run's own SHA from deletion regardless
of sort order, as defense in depth against any remaining timestamp edge
cases.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GITOPS_PAT auth was failing against Forgejo. GitHub is the source of
truth for nxtgauge-gitops; push there and let sync-to-forgejo.yml
relay to Forgejo, which Flux actually watches.
Third bug in the same chain: GITEOPS_REPO/GITEOPS_SSH_KEY were
referenced but never actually configured as repo secrets (only
REGISTRY_*, GITOPS_GITHUB_*, and GITOPS_PAT exist) — the digest
extraction fix got the job to actually reach this step, where it then
failed instantly and silently (a bare `test -n` with no echo). Switch
to an HTTPS clone with GITOPS_PAT, matching nxtgauge-backend-rust's
already-working workflow.
The docker gateway fix got the build to actually run and push
successfully, but the digest-extraction grep required a compact
":" with no space, while buildx writes the metadata file
pretty-printed ("containerimage.digest": "sha256:..."), so the match
always failed, aborting the step post-push and skipping the
GitOps-release step entirely. Match nxtgauge-backend-rust's
whitespace-tolerant pattern.
Every build on this branch has been failing with "Cannot connect to
the Docker daemon at tcp://127.0.0.1:2375" — the job container is
nested one level inside the runner pod's dind sidecar, so its own
loopback isn't the sidecar's. nxtgauge-backend-rust already carries
the fix (read the container's default-route gateway from
/proc/net/route); porting the same step here.