fix(ci): gh pr create has no --jq — the bump PR still could not be created - #2552
Merged
Merged
Conversation
…eated #2542 fixed the missing GH_TOKEN, and the dispatch after it merged got further than this workflow has ever got: check-upstream now SUCCEEDS and create-pr ran for the first time. It then failed on the next layer. unknown flag: --jq Usage: gh pr create [flags] `gh pr create` prints the PR URL on stdout. It has no --json, so it has no --jq; passing one makes gh dump its usage and exit 1. The PR number is the last path segment of the URL. This is the fourth defect in a row that could only appear once the one in front of it was fixed, and none of them were reachable by reading: 1. missing GH_TOKEN on a step gated to run only when a bump is due (#2542) 2. gh pr create --jq (this) with the same shape on yt-dlp-bump (nested gitlink -> uppercase GHCR tag -> swallowed gh failure -> hardcoded x86_64 deno). Each fix is the only way to see the next one. Swept every --jq in .github/workflows and checked which gh subcommand each belongs to: gh pr list, gh api, gh run list/view, gh repo list, gh label list and gh issue list all support --json and are fine. gh pr edit and gh pr comment appeared to be misusing it but were false alarms — the nearby --jq belongs to a gh run list on a following line. This is the only real instance. Also pre-checked the next candidate failure so it does not become layer three: both labels the step applies, upstream-update and dependencies, exist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Important Review available on request
Reviews should be triggered manually for repositories with fewer than 10 stars. Select Trigger review above or comment ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
POWERFULMOVES
added a commit
that referenced
this pull request
Aug 14, 2026
…es (#2553) 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>
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.
The next layer
#2542 fixed the missing
GH_TOKEN. Dispatching after it merged got further than this workflow has ever got —check-upstreamnow succeeds, andcreate-prexecuted for the first time in its life. It failed immediately:gh pr createprints the PR URL on stdout. It has no--json, so it has no--jq— passing one makesghdump its usage and exit 1. The number is the last path segment of the URL.Four defects, each hidden behind the one in front
GH_TOKENon a step gated to run only when a bump is due (#2542)gh pr create --jq(this PR)with the identical shape already worked through on
yt-dlp-bump: nested gitlink → uppercase GHCR tag → swallowedghfailure → hardcodedx86_64deno.None were reachable by reading. Each fix is the only way to see the next, because every one of them sits behind a gate that only opens when the previous is repaired. That is the whole reason this lane went unnoticed for months while reporting green.
Sweep
Checked every
--jqin.github/workflowsagainst theghsubcommand it belongs to:--jsonexists):gh pr list,gh api,gh run list,gh run view,gh repo list,gh label list,gh issue listgh pr edit/gh pr commentlooked like misuse but were false alarms — the nearby--jqbelongs to agh run liston a following lineThis is the only real instance.
Pre-checked so it doesn't become layer three
Both labels the step applies —
upstream-updateanddependencies— exist. A missing label would have been the next failure.🤖 Generated with Claude Code