fix(ci): stop scheduling the drift check until the App can read settings - #145
Conversation
The token request itself is refused - 422, the permissions requested are not granted to this installation - because the App does not have Administration: Read-only, and GitHub returns a repository's merge-policy and feature settings to no lesser scope. A daily run would therefore fail every day on something no change in this repository can fix. Dispatch stays available, and the schedule is a one-line restore once the permission lands. The check is not narrowed to the fields a metadata token can see: quietly comparing fewer fields than the config declares is the failure this check exists to catch. Part of #144
@coderabbitai review |
|
|
|
Warning Review limit reached
Next review available in: 20 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
CodeRabbit refused ( @codex review |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Codex refused too — |
|
@cursor review |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_39b02f5b-8a57-4f53-8708-d0d54c1bb6ad) |
devantler
left a comment
devantler
left a comment
There was a problem hiding this comment.
🤖 Generated by the Agentic Engineer
Self-review (fallback — CodeRabbit, Codex and Cursor Bugbot unavailable)
Reviewed commit: 34e10668eee16e5ce141d33b4da8043c55d10163
| Lane | Outcome at 34e1066 |
When |
|---|---|---|
| CodeRabbit | Action not completed / Review rate limited, plus a Review limit reached summary |
10:56Z |
| Codex | You have reached your Codex usage limits for code reviews |
10:56:52Z |
| Cursor Bugbot | check-run neutral / output.title: Error |
10:57Z |
What I checked
The blocker is measured, not assumed. Two dispatched runs establish it: at 10:46Z with
metadata: read the check aborted on the first repository because GitHub omitted allow_auto_merge;
at 10:53Z with administration: read added, the token step itself failed with
422 The permissions requested are not granted to this installation. So the App does not hold the
permission, and requesting one an installation lacks is a hard failure rather than a downgrade.
Neither wall was visible before merge — a workflow_dispatch workflow cannot run until it is on the
default branch.
Scope of this change. One trigger removed, comments added. The check script, its tests, the token
scoping and the job body are untouched, and workflow_dispatch is retained so the check can still be
run on demand and so the restore is a one-line diff. actionlint and zizmor clean; the offline
fixture suite still passes; CI green.
Why not narrow the check instead. Comparing only the fields a metadata token returns would make
the workflow green again today, and it is the wrong trade: it would quietly cover fewer fields than
deploy/ declares, which is the precise failure mode this check exists to detect, and the fields
that would disappear are the ones that produced its only real finding so far (#141, world-at-ruin's
merge policy). A loud pause with the coverage intact is preferable to a green check that has stopped
looking.
Is removing a trigger a security regression? No control is being weakened: the check cannot
currently run in any form, so there is no protection being given up — only a daily failure that no
change in this repository can clear. The compensating action is the grant requested in #144, and the
restore is pinned there as an acceptance criterion so it cannot be quietly forgotten.
Verdict: no P0/P1 findings.
1 participant
Why
The repository drift check I merged an hour ago cannot run at all. It needs to read each repository's
merge and feature settings, and GitHub hands those out only to a caller with administrative read —
which the App behind our workflows does not currently have. The request for it is refused outright,
so the daily run would fail every morning on something no change in this repository can fix.
Granting that access is an organisation-owner action, so it is tracked separately in #144.
What
Takes the check off the daily schedule until then. It can still be run on demand, and turning the
schedule back on is a one-line change.
It deliberately does not shrink the check to the handful of settings the current access can see.
Quietly checking fewer things than the config claims to control is the exact problem this check was
built to catch, and it would have hidden the one real divergence it has already found (#141).
Part of #144