Problem

The publish-chart job in build-images.yml failed on main (run 27535189783) at the Commit version bumps back to main step:

! [rejected]        HEAD -> main (non-fast-forward)
push failed; rebasing onto refreshed origin/main and retrying
   03af566..28de74f  main       -> origin/main
CONFLICT (content): Merge conflict in charts/insight/values.yaml
rebase failed (conflict on bumped files?); aborting
Process completed with exit code 1.

Re-running the job reproduced the failure identically — confirming this is not a transient race but a structural defect.

Root cause

publish-chart both patch-bumps the umbrella version and rewrites ingestion.toolboxImage in charts/insight/values.yaml, reading from / writing to the tree checked out at the run's trigger SHA.

Two PRs that both touch src/ingestion/** were merged back-to-back:

ae60ce3  feat: Figma connector   (#1306)   merge #1
03af566  feat: Workday connector (#1305)   merge #2  <- trigger SHA of the failing run

Each merge triggers an independent run, and because both touch ingestion, both rebuild the toolbox. The second run's trigger SHA (03af566) does not contain the first run's chore(release) commit, so both runs:

• compute the same next umbrella version (0.1.67), and
• rewrite the same ingestion.toolboxImage line to their own build tag.

The first run (28de74f) pushes its release commit; the second run's commit-back is then rejected (non-fast-forward). The retry's git pull --rebase conflicts in charts/insight/values.yaml — specifically on the ingestion.toolboxImage line (the version line auto-merges, both sides wrote 0.1.67) — and aborts → exit 1. A plain job re-run repeats forever because checkout re-pins the same stale SHA.

Secondary symptom: both runs helm push chart 0.1.67 with different contents (different toolbox tags), so the artifact published to GHCR diverges from what main records as 0.1.67.

Why other approaches don't fit

• concurrency is already set (build-images-${{ github.ref }}, cancel-in-progress: false) and serialises runs — but each run is still pinned to its own trigger SHA, so it doesn't help; if anything it makes the stale-base collision near-certain for close merges.
• cancel-in-progress: true is incompatible with this pipeline: change detection is per-push (diff vs parent), so cancelling an intermediate run drops that commit's image builds, and the connector descriptor recursion-break relies on the parent-diff — basing it on the last release instead would cause an infinite rebuild loop.
• Merge queue serialises PR merges, but the release commit-back is a separate async workflow keyed on push to main, outside the queue — so it doesn't gate the racing release runs.

Fix

• Re-anchor to the live branch tip (git fetch + git reset --hard origin/$GITHUB_REF_NAME) at job start, before any value is computed. Version-compute, the toolboxImage ref, and the commit-back are now all consistent with the branch tip, and a re-run recomputes against the refreshed tip instead of replaying a stale SHA.
• Replace the fragile rebase-retry with a fail-loud guard. With the re-anchor plus the existing per-ref concurrency serialisation, the final push fast-forwards; the only remaining way the tip moves is a direct human push, where rebasing the bump is unresolvable anyway.

Scope note

bump-descriptors shares the same rebase-retry pattern. Left untouched here to keep this PR scoped to the reproduced failure; can follow up if desired.

Testing

• python3 -c "import yaml; yaml.safe_load(...)" passes (YAML valid).
• Logic verified against the failing run's logs; the re-run reproduced the exact failure this fix targets.

🤖 Generated with Claude Code