git-cli: `run watch --branch` misses PR-gate runs (pull_request event has empty branch)

[St0nefish]

Summary

git-tools run watch --branch <feature-branch> reports

status: no-workflow
CI workflow runs exist but none correlate to branch '<feature-branch>' after 120s

even though CI did run for the pushed commit. This makes the ship skill's "watch CI" step (step 5) ineffective on repos whose CI triggers on pull_request rather than on the branch push.

Root cause

run watch correlates runs by branch name. But for a repo whose CI runs on on: pull_request:, the resulting run carries an empty branch field (and a pull_request event), so a feature-branch-name match finds nothing. Any post-merge runs are on master (push event), which also don't match the feature branch.

Observed via run list for my pushed SHA 8061c52…:

run id	event	branch
1073	pull_request	""
1074	push	master
1075	push	master

run watch --branch worktree-feature-306-… matched none of these → no-workflow, despite run 1073 being the PR gate for exactly that commit.

Impact

In the ship flow on such a repo, the watch step is a no-op; I had to fall back to polling run list filtered by head_sha to actually watch CI to completion.

Suggested fix

Correlate by head_sha of the current HEAD commit (in addition to / as a fallback for branch name). The pushed commit SHA is stable across pull_request and push events and across the feature→master merge, so it reliably identifies the relevant run(s) where the branch name does not.

Environment

• git-tools 2.0.10 (plugin cache)
• tea 0.14.1
• Platform: Gitea; CI model: on: pull_request: branches: [master] with an auto-merge job

[St0nefish]

Still reproduces on git-tools 2.0.13 (plugin cache), and notably the attempted fix that already shipped does not resolve it.

Fresh repro (v2.0.13, self-hosted Gitea)

ship step 5 ran run watch --branch chore-confirm-hermes-config --timeout 600 --interval 30 and returned:

status: no-workflow
duration: 120s
CI workflow runs exist but none correlate to branch 'chore-confirm-hermes-config' after 120s

…while CI had in fact run and passed and the PR auto-merged. run list for the pushed SHA c11506d…:

run id	event	branch	head_sha	status
1144	pull_request	""	c11506d…	success
1145	push	master	c11506d…	success

Same shape as the original report: the pull_request gate run (1144) has an empty branch, so the --branch correlation drops it.

The PR #108 / v2.0.9 fix is incomplete

run list's Gitea path was already reworked (PR #108, v2.0.9; present in 2.0.11 and 2.0.13) to stop relying on tea's server-side --branch filter — it now fetches unfiltered via tea api and normalizes branch from head_branch, then filters client-side (plugins-claude/git-tools/scripts/git-cli, ~L759–774):

branch: (((.head_branch // "") | select(. != "")) // (.branch // "")),
...
| if $b == "" then . else [.[] | select(.branch == $b)] end

But Gitea returns head_branch: "" as well on pull_request-triggered runs (same as .branch). So the normalization yields "" and select(.branch == $b) still filters every PR-gate run out. The client-side rework addressed the server-side filter but not the root cause, so the bug survives untouched.

The suggested head_sha fallback still isn't wired in

head_sha is already emitted in the normalized run objects (~L767) but is never used for correlation. The fix this issue proposes — fall back to head_sha == <branch HEAD commit> when .branch/.head_branch is empty — remains the correct one and is unimplemented.

Why --timeout 600 looked ignored

The watcher bailed at exactly 120s, not 600s, because the no-run deadline is initial_delay + 2*interval (~L1135) = 60 + 2*30 with ship's --interval 30. --timeout only gates the polling loop after a run is correlated; when correlation never succeeds, the loop exits at the no-run deadline regardless of --timeout.

Also confirms #140 item 1

For the merged PR, pr show returned state: merged but merged: false / mergedAt: null (consistent with #140) — so I verified the merge via state + run list filtered on head_sha rather than run watch.

Env: git-tools 2.0.13 (cache; repo HEAD is 2.0.11), Gitea, CI on pull_request with auto-merge on green.