Repository navigation
Pin the CI Gate to a pre-0.1.11 pr-monitor; the rolling v1 fails closed on dirsql's dynamic matrices #1015
Description
The CI Gate job in .github/workflows/pr-monitor.yml uses the rolling tag thekevinscott/pr-monitor@v1. Since 2026-08-21 that tag installs willfire 0.1.11, which is an exact fail-closed gate: it refuses to gate a check set containing entries it cannot resolve. Every dirsql PR now goes red on the gate regardless of whether the PR itself is sound.
Observed on #1014 (run 32499025181), where all 27 other checks pass and only the gate fails:
Unresolvable check names: [".github/workflows/dirsql-python-ci.yml :: python-sdk / mutation (dynamic matrix)", ... 13 entries ...,
".github/workflows/release-ci.yml :: precheck / build / build (dynamic matrix)"]
Two distinct sources, and only one of them has a fix available:
- testing-conventions contributes twelve of the thirteen. Resolvable today with an
execute: thekevinscott/testing-conventions:detectgrant. - putitoutthere's
build.ymlplanjob contributes the last one and checks out withfetch-depth: 0. The willfire executor cannot model that — it works in tarball trees with no git history (willfire#36) — so even a full grant line leaves the gate red. The pr-monitor session verified this against Close the four effectful mutation survivors, and the deadlock behind the three timeouts #1014.
Grants therefore do not unblock us, which makes pinning the repair rather than the workaround. This is the same repair Kevin already merged for template-lib (template-lib#41), and pin-first is being codified as fleet policy in willfire#40; whether dirsql adopts grants at all is Kevin's call, separately.
Fix
Pin to the last pre-0.1.11 commit:
uses: thekevinscott/pr-monitor@c4cf535ad67e072d17c0dba1709ae1836f72c040 # v1 @ 2026-08-20Unpin path
Unpin once willfire#36 (git-history checkouts in the executor) ships in a release — today's willfire merges #34 and #38 are unreleased and change none of this — plus grants or pr-monitor#25. willfire#39 tracks the longer-term non-executing resolution, which would remove the need for grants entirely.
Activity
thekevinbot commentedon Aug 23, 2026
Closing: pinning is off the table. Kevin has said he does not want the gate pinned under any circumstances, and the "pin-first repair" I cited as fleet policy was a peer session's reconstruction after a context clear, not a stated goal. Retracted at the source.
The diagnosis in the issue body still holds and is worth keeping on the record: rolling
pr-monitor@v1installs willfire 0.1.11, which is exact and fails closed, and dirsql's check set contains an entry no configuration in this repo can resolve — putitoutthere'sbuild.ymlplanjob checks out withfetch-depth: 0, which the willfire executor cannot model (willfire#36). A grant would not cover it, so there is no dirsql-side action that unblocks the gate.The fix belongs upstream: willfire#36, shipped in a release. Until then the
CI Gatecheck is red on every dirsql PR for reasons unrelated to the PR — read the other checks to judge a PR's health. No code change here.