fix(ci): the bump workflow was wedged by the debris of its own failures - #2553
Merged
Conversation
Third layer, and the first one that is a design bug rather than a typo. After #2542 (missing token) and #2552 (gh pr create --jq), the dispatch failed EARLIER than before — at "Commit and push", a step that had passed on the run before: error: failed to push some refs to 'https://github.com/POWERFULMOVES/PMOVES.AI' Cause: chore/agent-zero-upstream-v2.9 already exists remotely (13cbb5a). The previous run pushed the branch and THEN died at PR creation, leaving the branch behind with no PR attached. The guard checks for an existing PULL REQUEST, not an existing BRANCH. So every subsequent run decides a PR is needed, recreates the same commit, and fails non-fast-forward. The workflow had permanently wedged itself with its own leftovers — and would have stayed wedged even with the first two defects fixed. That is the sharpest form of the pattern in this lane: the failures were not independent, they compounded. Months of create-pr never running meant months of opportunity to strand a branch, and the strand then blocks the repair. Fix: delete the remote branch before pushing. Safe here specifically because create-pr only runs when check_pr found NO open PR (see its `if:`), so a branch reaching this point has no PR attached and is by definition debris. Deleted rather than force-pushed so the intent is explicit and the blast radius is visible: a maintainer's in-progress work on a real bump PR is never touched, because that branch would have a PR and this job would not run. The existing stranded v2.9 branch is deliberately NOT deleted by hand — the fixed workflow clears it on its next run, which also proves the fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8ae1d3437
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # Deleted rather than force-pushed so the intent is explicit, and | ||
| # narrowed to a branch with no open PR so a maintainer's in-progress | ||
| # work on a real bump PR is never touched. | ||
| git push origin --delete "${BRANCH}" 2>/dev/null || true |
There was a problem hiding this comment.
When a maintainer has closed a bump PR without merging it, or has pushed work to this deterministic branch before opening a PR, this command deletes and replaces those commits on the next scheduled run. The preceding gh pr list does not prove that the branch is debris: its help explicitly says “By default, this only lists open PRs,” and --state defaults to open. Check all PR states and verify that the remote branch matches a known bot-created stale commit before removing or replacing it; otherwise the workflow can discard maintainer work and recreate a deliberately closed PR.
Useful? React with 👍 / 👎.
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 14, 2026
…I job (#2555) Fourth and last layer. With #2542, #2552 and #2553 in, the workflow finally did its job — create-pr SUCCEEDED and opened #2554, "bump upstream to v2.9", the first bump PR this workflow has ever produced. post-ci then failed: /home/runner/work/_temp/....sh: line 31: syntax error: unexpected end of file The "Handle CI result" step wrote its comment with cat > /tmp/failure_comment.md << 'COMMENT' ... COMMENT <- indented `<<` requires the delimiter at column 0. `<<-` strips leading TABS only, not the spaces this file is indented with. So bash never found the terminator, swallowed the remainder of the script, and died at EOF. The step could never have run. Reproduced and verified both directions rather than asserted: old step, bash -n: warning: here-document at line 13 delimited by end-of-file (wanted `COMMENT') line 31: syntax error: unexpected end of file exit 2 new step, bash -n: clean That old error is character-for-character what the CI run printed. Replaced the heredoc with a brace group redirected to the file. That also removes a second latent bug in the same step: the placeholder+sed dance it needed used sed -i "s|PLACEHOLDER|${FAILED_JOBS:-"- CI did not..."}|" ... which nests double quotes inside a double-quoted sed expression. The brace group needs no placeholder and no sed, so both problems go away rather than being patched. Running total on this one workflow, each defect reachable only after the one in front of it was fixed: 1 missing GH_TOKEN, on a step gated to run only when a bump is due #2542 2 gh pr create --jq #2552 3 stranded branch blocked the push #2553 4 indented heredoc terminator this Every one of them sat behind a gate that only opens when its predecessor is repaired. That is why months of green meant nothing. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third layer — and the first that is a design bug, not a typo
After #2542 (missing
GH_TOKEN) and #2552 (gh pr create --jq), the dispatch failed earlier than before, at a step that had passed on the previous run:chore/agent-zero-upstream-v2.9already exists remotely (13cbb5a0). The previous run pushed the branch and then died at PR creation, stranding it with no PR attached.The guard checks for an existing pull request, not an existing branch. So every run since decides a PR is needed, recreates the same commit, and fails non-fast-forward.
The workflow had permanently wedged itself with its own leftovers — and would have stayed wedged even with the first two defects fixed.
Why this one matters more than the others
The failures were not independent, they compounded. Months of
create-prnever running meant months of opportunity to strand a branch — and the strand then blocks the repair. A gate that cannot report its own failure doesn't just stay silent; it accumulates state that defeats the fix.Running tally on this one workflow:
GH_TOKENon a step gated to run only when a bump is duegh pr create --jqSame shape already worked through on
yt-dlp-bump: nested gitlink → uppercase GHCR tag → swallowedghfailure → hardcodedx86_64deno.Fix, and why it is safe
Delete the remote branch before pushing.
This is safe specifically because
create-pronly runs whencheck_prfound no open PR (see itsif:). A branch reaching this point therefore has no PR attached and is by definition debris.Deleted rather than force-pushed so the intent is explicit and the blast radius is visible: a maintainer's in-progress work on a real bump PR is never touched, because that branch would have a PR and this job would not run at all.
Verification
The stranded
v2.9branch is deliberately not deleted by hand. The fixed workflow clears it on its next run — which also proves the fix, rather than hiding it behind manual cleanup.🤖 Generated with Claude Code