Watch PR

The monitor

Emits one line per check as it lands, then one line when the run is over. Copy it as-is and change PR:

cd 'c:\Users\shaneb\git\OpenTagViewer'
PR=99
seen=""
while true; do
  now=$(gh pr view "$PR" --json statusCheckRollup --jq \
        '.statusCheckRollup[] | select(.status == "COMPLETED") | "\(.name): \(.conclusion)"' 2>/dev/null | sort)
  comm -13 <(printf '%s\n' "$seen") <(printf '%s\n' "$now")
  seen="$now"
  total=$(gh pr view "$PR" --json statusCheckRollup --jq '.statusCheckRollup | length' 2>/dev/null)
  if [ "$total" = "0" ]; then
    echo "PR #$PR: NO CHECKS EXIST - nothing is verifying this. See the section above."
    break
  fi
  if [ "$(gh pr view "$PR" --json statusCheckRollup --jq \
          '[.statusCheckRollup[].status] | length > 0 and all(. == "COMPLETED")' 2>/dev/null)" = "true" ]; then
    echo "PR #$PR: all $total checks finished"
    break
  fi
  sleep 30
done

The zero case is checked separately, and that is not belt-and-braces. [] | all(...) is true in jq, so without it an empty rollup exits immediately announcing "all checks finished" — a monitor reporting success over a PR that ran nothing at all. That happened on #105.

timeout_ms: the emulator suite here takes several minutes and the whole run rarely exceeds 20, so 2700000 (45 min) is comfortable. persistent: false — it ends itself.

Why it is shaped this way:

• comm -13 against the previous set reports each check once, as it finishes, rather than re-reporting the finished ones every 30 seconds.
• printf '%s\n', not echo, so an empty seen is one empty line and comm behaves.
• It reports failures as readily as successes. A filter matching only SUCCESS stays silent through a red build, and silence reads as "still running".
• 2>/dev/null on the gh calls, but no || continue. A transient API failure yields an empty result and the loop tries again; it must not be able to exit quietly.
• length > 0 and before the all, because all on an empty list is true. Without it the loop declares victory the instant the rollup is empty — which is exactly what a freshly pushed commit looks like before GitHub has created its runs, and what a fork PR waiting on "Approve and run" looks like indefinitely. It printed all checks finished for a PR with zero checks, one line after a push, and that reads identically to a green build.

A fork PR can sit at action_required forever, and that is not a failure state. GitHub gates workflow runs on PRs from forks, so gh run list shows completed / action_required and gh pr checks says "no checks reported". Nothing is wrong and nothing will happen until a maintainer approves:

gh run list --limit 5 --json databaseId,headSha,conclusion \
  --jq '.[] | select(.conclusion=="action_required") | .databaseId'
gh api -X POST repos/<owner>/<repo>/actions/runs/<id>/approve

When it lands

• Green — merge if that was asked for, otherwise say it is green and offer. gh pr merge <n> --merge --delete-branch. Then git fetch && git rebase origin/main on anything stacked on it.

• Red — read the failing step and fix it. --log-failed refuses while a run is still going, so get the step list from the API first:

  gh pr checks <n>                                    # which job, and its URL
  gh api repos/parawanderer/OpenTagViewer/actions/jobs/<job-id> \
    --jq '.steps[] | "\(.conclusion // .status)\t\(.name)"'
  gh run view --job <job-id> --log-failed | tail -30   # once the run has finished

  Read the failure before assuming it is flaky. On #99 a red build was not CI noise: it was the repo type-checking against PyPI's FindMy while the app built a fork, which was a real defect the failure exposed.

• Pushed a fix? Re-arm. A green run on the previous commit says nothing about this one.

Related

• AGENTS.md on gh — why an agent without it can only guess at a red build.
• The memory notes propose-watching-a-pushed-pr (act on the one just pushed) and sweep-open-prs-read-only (look at all the others, and only look).