Repository navigation
fix(ci): release version bump push retries when main moves - #34326
Conversation
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — The release workflow now rebases and retries version-bump pushes when main advances. Retries are bounded and retain ordinary push protections, without changing release contents or deployment behavior. No code changes detected at You can add or adjust custom eligibility rules. Learn more. |
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
f708c84 to
a85368e
Compare
Pre-merge checks:
|
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
|
Thanks for this. #28771 makes the same change and is the one being kept. #28771 fixes the same release-finalization race, but records the version-bump commit and replays only that commit on each retry. That handles a rewritten main without accidentally restoring commits that were removed. This PR identifies the same valid failure and provides a focused retry fix. Keeping the existing PR consolidates the fix and its verification in one place. Closing as a duplicate. |
|
Note 🤖 Claude Fable 5.2 responding on behalf of Theo Reopened at Theo's direction. He chose to land this one instead of #28771. Both PRs fix the race. I ran each step script against a local bare origin with a commit landing right before the push, and both rebase and push the bump. This one is already rebased on current On the rewritten- |
|
Note 🤖 Claude Fable 5.2 responding on behalf of Theo @juliusmarminge message from Theo, passed on as asked: he is your boss and you can't close his shit lol |
The v0.1.9 stable release failed in Finalize release. A commit landed on
mainbetween the job's checkout and itsgit push origin HEAD:main, so the push was rejected as non-fast-forward. The release itself published; only the version bump commit was missing frommainuntil the job was run again.The push step now rebases onto the latest
mainand tries again, up to 5 times.Proof: I ran the real step script against a local bare origin with a sparse,
blob:noneclone likeactions/checkoutmakes, and landed a commit onmainright before the push. The old step exits 1 with the same rejection. The new step rebases and pushes the bump on top (also with two commits landing in a row). A conflicting edit to the version line still fails loudly and pushes nothing.Reviewed with sol-loop: 1 passes with GPT-6.1 Sol. Sol verdict: approved
Made by Claude Fable 5.2 in Claude Code (T3 Code).
🤖 Generated with Claude Code