Files
qwen-code/docs
Shaojin Wen 4c8ebeab4d feat(core): view one pull request by URL for the PR-state watch (#16530)
* feat(core): view one pull request by URL for the PR-state watch

Add fetchGitHubPullRequestView(url, cwd, env?), the single-PR view the
daemon's PR-state watch will use (step two of PR A in
docs/design/2026-11-04-daemon-pr-state-transitions.md, section 1). It
runs `gh pr view <url> --json url,title,headRefOid,mergeable,state,
statusCheckRollup` and returns the canonical URL, title, head SHA,
open/merged/closed, mergeable (absent while GitHub reports UNKNOWN), the
CI state and the failing check names (`<workflow> / <job>`, the check
name or the status context; once each, at most 20).

Only an http(s) /owner/repo/pull/<n> URL is accepted, and it is rebuilt
without credentials, query, fragment or tab path before it reaches gh,
so an issue URL, /PULL/7 or /pull/0 never becomes a branch lookup. The
working directory must exist, so a missing one is not reported as gh
being unavailable. Failures carry a reason (not_a_pr_url, cwd_missing,
gh_failed, timed_out, unparsable). There is no host check; the caller
restricts URLs to the allowed GitHub hosts.

aggregateChecks is exported with unchanged behaviour; its failing-entry
predicate is shared with the failing-name extraction. Every rollup entry
still counts: gh's JSON exports no event, app or workflow id, and a
dedupe by names and times would let a skipped or other-trigger run hide
a current failure.

The design doc's Files-affected row for core names the real signature
and fields.

* fix(core): report gh's diagnostic, not Node's argv, when gh fails

execFile's callback error has no stderr property (only the promisified
form attaches it), so ghErrorMessage fell back to Node's "Command failed:
<argv>" message: a failed PR list, view or create reported the gh command
line (for create, the PR title and body) ahead of gh's diagnostic, which
the 4,096-character raw cap and the route's 512-character display cap
could then cut off. The three callback wrappers now attach the
callback's stderr, as the PR issues wrapper already does.

When gh exits or is signalled with nothing on stderr, the message names
the exit code or the signal instead of falling back to the argv, and a
failure Node raises itself (a string code such as a spawn error or an
overflowing buffer) keeps Node's message even if gh wrote something.
`gh api graphql` failures of the PR issues fetch, which share the
helper, get the same treatment.

The test helper now fails the way execFile does: an exit 1 unless told
otherwise, with stderr only as the callback's third argument, so the
stderr tests exercise the wrappers and the stderr-over-exit-code order
rather than the mock. Tests cover a silent exit, a signal, a buffer
overflow with stderr, and a silent create that must not echo the title
and body; the view's failing-names test gains a failing check run with
an empty name and a status context with an empty context, which fail the
head but are not named.
2026-11-07 21:33:43 +08:00
..
2025-12-05 10:51:57 +08:00
2025-12-19 15:52:11 +08:00