Let a text-capable guard stand in front of a command - #6
Conversation
Three repositories wrote `command.before` on `no-private-repo-names` and the loader refused all three, on grounds that were true and unhelpful: a built-in is not an `exec`, and `shim::run` consulted only `exec` rules. They were not writing it by mistake. That guard reads the commit message at every git hook, and a repository whose own prose cites its issues gets every one of those citations refused -- GroundGate says so in the policy file, in a paragraph explaining why the rule deliberately carries no `git.hooks`. So the seam it belongs at is the command that publishes text to a forge, and there was no field to say that in. Every alternative was worse: `git.hooks = ["commit-msg"]` refuses the citations, `git.hooks = ["manual"]` refuses them at CI instead, and no place at all is refused at load. So the shim consults text-capable built-ins as well as `exec` checkers, scoped by the same `command.before`, through the same dispatch `uphold guard --text` uses -- a guard that judged a commit message one way and a pull-request body another would be two rules under one id. The loader allows the field for those three built-ins and still refuses it for anything that reads an index, an identity or a push range, with a message that now names which ones can. And the "this shim is checked by nothing" refusal counts a built-in as a checker, having previously refused a policy whose shim was checked by a guard rather than by a script. The fleet goes from 68 of 71 repositories reconciling to 71 of 71. The three were not misconfigured; the vocabulary was short a word.
|
Warning Review limit reached
Next review available in: 23 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: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
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 |
Codecov Report❌ Patch coverage is
❌ Your patch status has failed because the patch coverage (95.38%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #6 +/- ##
==========================================
+ Coverage 87.63% 87.74% +0.10%
==========================================
Files 24 24
Lines 7094 7140 +46
==========================================
+ Hits 6217 6265 +48
+ Misses 877 875 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
2 participants
Three repositories wrote
command.beforeonno-private-repo-names. The loaderrefused all three, on grounds that were true and unhelpful: a built-in is not an
exec, andshim::runconsulted onlyexecrules.They were not writing it by mistake. That guard reads the commit message at
every git hook, so a repository whose own prose cites its issues gets every one
of those citations refused. One of the three says exactly this in its policy
file, in a paragraph explaining why the rule deliberately carries no
git.hooks. The seam it belongs at is the command that publishes text to aforge — and there was no field to say that in.
Every alternative was worse, and I tested each:
git.hooks = ["commit-msg"]git.hooks = ["manual"]command.beforeWhat changed
shim::runconsults text-capable built-ins alongsideexeccheckers, scoped bythe same
command.before, through the same dispatchuphold guard --textuses.That last part is the point: a guard that judged a commit message one way and a
pull-request body another would be two rules wearing one id, so the dispatch is
extracted into
guard::text_refusaland both seams call it.The loader allows the field for the three built-ins that can judge arbitrary
text and still refuses it for anything reading an index, an identity or a push
range — with a message that now names which ones qualify, instead of only saying
what the rule is not.
And the "this shim is checked by nothing" refusal counts a built-in as a
checker. It previously refused a policy whose shim was checked, by a guard
rather than by a script.
Why this and not three policy edits
This began as a plan to fix three repositories. Checking the refusal first
turned it around: the shape is legitimate, the vocabulary was short a word, and
editing the three would have meant either accepting refused citations or
inventing a placement that means nothing.
Verification
cargo test— 300 tests. Six new: the loader accepts the shape for each textguard and still refuses it for two non-text built-ins and a regexp rule; the
shim refuses a private name in a PR body, lets a clean body through to the
real command, and accepts a shim whose only checker is a built-in.
a_command_place_the_check_cannot_use_is_refusedusedprevent-ai-author,which is a text guard and is now legal. It tests two non-text built-ins
instead, which is what it was always about.
cargo clippy --all-targetsandcargo fmt --checkclean; the repository'sown hooks pass;
uphold scananduphold checkover this tree are clean.