git diff --quiet (no --cached) compares the working tree to the index,
not the index to HEAD. It ran right after git add, at which point the
working tree always matches the index - so it reported "no changes"
unconditionally, on every single run, regardless of whether the sed
substitution actually changed anything relative to HEAD. This silently
skipped the gitops commit+push every time (job still exited 0), which
is why the deployed digest never advanced across ~15 build runs.
Switched to git diff --cached --quiet, and added step-by-step echo
diagnostics so a future silent failure is visible in the run log
instead of just vanishing between two log lines.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The gitops-update sed only matched the old tag-based image reference
(image: ...:SHA). After the digest-pinning fix in nxtgauge-gitops
(release-patch.yaml now uses @sha256:... to stop Flux's
ImageUpdateAutomation from racing this file), the regex silently
matched nothing, git diff showed no change, and every build since
has skipped deploying - the cluster stayed on an old digest despite
CI reporting success. Now captures the pushed image's digest via
buildx's --metadata-file and writes @sha256:<digest> directly.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Third failure: ashwin/nxtgauge-gitops's server-side HEAD symref is broken
("remote HEAD refers to nonexistent ref" on plain clone, even though
refs/heads/main exists via the API) - a Forgejo-level repo quirk, not
something to fix here. backend-rust's workflow survives this by accident
(it does an explicit git checkout after cloning); clone with -b main
directly instead of relying on HEAD resolution at all.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Second failure: pushing to ci.nxtgauge.com/nxtgauge/nxtgauge-ai-assistant
404'd because no "nxtgauge" org exists on this Forgejo instance. The image
this app actually runs (verified against the live k8s deployment) lives
under ci.nxtgauge.com/ashwin/nxtgauge-ai-assistant, and the real GitOps
target is apps/nxtgauge-ai-assistant/overlays/prod/release-patch.yaml in
ashwin/nxtgauge-gitops (which Flux's image-automation-controller also
tracks via its $imagepolicy marker), not base/deployment.yaml.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
First real run after fixing the registry/secrets config failed immediately
with "Cannot connect to the Docker daemon at tcp://127.0.0.1:2375" - the
job container is nested inside the runner pod's dind sidecar, so its own
loopback isn't the sidecar's. Port the gateway-detection step already
working in nxtgauge-backend-rust's workflow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The GitOps step relied on GITEOPS_REPO/GITEOPS_SSH_KEY secrets that were
never configured, and the registry login used a REGISTRY_HOSTPORT secret
that doesn't match this repo's actual registry setup. Switch to the
Forgejo registry directly and push the GitOps update over HTTPS with a
token, matching how other services in this org already deploy.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
