Every scheduled sweep failed at token minting since the explicit
permission subset was added: actions/create-github-app-token rejects any
request exceeding the installation grant, and these installations lack
actions:write/checks:read (stale.yml succeeds with actions:read;
auto-response succeeds with neither). Requesting no subset restores the
app's full granted set, which the re-fire lane demonstrably worked with.
If the org later grants actions:write+checks:read, the explicit subset
can return.
* fix(scripts): ignore superseded workflow runs in watch-pr-ci rollup classification
Draft->ready re-triggers leave cancelled superseded runs on the head SHA
forever, and GitHub's aggregate rollup state counts them, so the watcher
emitted terminal FAILURE while the replacement run was still in progress
and could never reach GREEN (observed on PR #113150, head bd1b9a0e).
- fetch run identity per check and resolve same-name checks to the newest
run/check id (GitHub latest-name-wins); drop cancelled checks from
replaced runs; keep older runs' unique jobs visible
- paginate statusCheckRollup contexts (bounded, 10 pages) so >100-context
rollups are not truncation-blind; changed or lost snapshots throw into
the bounded retry
- classify GREEN when aggregate FAILURE is explained solely by superseded
contexts with full visibility; truncation still fails conservatively
* ci: scope GitHub App token permissions in stale, labeler, auto-response, and pr-ci-sweeper
Fixes red main: #112963 bumped zizmor v1.22.0 -> v1.28.0, whose github-app
audit flags create-github-app-token mints without permission-* inputs (14
high findings, Workflow Sanity red on main since 3b7b2a2a1f). Most
workflows already migrated to scoped tokens; these four were stragglers.
Scopes follow each consumer's actual API surface: stale needs issues/PR
write plus actions read for its state-cache check; labeler needs label
CRUD (issues write), PR write, members read for maintainer gates, and
contents read where actions/labeler reads its config; auto-response needs
issues/PR write plus members read; pr-ci-sweeper needs actions write to
re-fire runs, checks read, and PR write. Verified locally with the exact
CI invocation (zizmor 1.28.0, repo config, regular persona, medium
severity/confidence): no findings, ignore/suppress counts match CI.
* ci: add hourly PR CI sweeper for dropped pull_request runs
Fresh PRs race GitHub's merge-ref computation: the open-event CI run can
drop entirely or be created as an un-rerunnable startup_failure (~10-16
runs daily). The sweeper lists recently updated open PRs hourly, finds
heads whose only pull_request-event CI runs are startup failures (or
missing), and re-fires the event by close/reopen with the Barnacle app
token (GITHUB_TOKEN events would not trigger workflows).
Safety: 10-minute quiet window, 24h lookback, skips drafts, merge
conflicts, pending mergeability, and auto-merge PRs (close cancels
auto-merge); revalidates state, head, and CI attachment immediately
before mutating; per-PR budget of two sweeper closes and a per-sweep cap
of ten; reopen-on-unknown ownership so a stranded close (silent) always
loses to a spurious reopen (visible); manual dispatch supports dry_run.
Accepted tradeoffs are documented inline: shared-SHA PR topologies can
mask a dropped run (skip-only miss; run.pull_requests matching would
break fork PRs), and app-auth failover at worst doubles the close budget.
* test(ci): exercise pr-ci-sweeper runner with a faked client
* fix(test): lint-clean pr-ci-sweeper runner fakes
Peter Steinberger