heygrc
Guide

Make compliance a required check, on your terms

A compliance review is most useful when it lives in the same place as your other checks. Here is how to think about blocking versus advisory, without turning your pipeline into a bottleneck.

Once a compliance review runs on every pull request, the next question is what to do with its result: should it block a merge, or just inform the reviewer? The honest answer is that it depends on the finding, and the mechanism should let you choose rather than force one posture on everything.

Blocking versus advisory

A status check that blocks every merge on any finding trains people to click past it. A check that never blocks anything gets ignored. The useful middle is advisory by default, with the option to require it through branch protection for the changes or repositories where a missed control is genuinely costly, like anything touching access control, cryptography, or personal data.

The decision is yours, not the tool's. A compliance reviewer should surface the finding and let your branch-protection policy decide whether it gates the merge.

How heygrc surfaces results

heygrc is built to post a GitHub check status alongside its review comments. That status is something you can optionally require in branch protection if you want a hard gate, or leave advisory if you want the finding visible without blocking. The intended default is a neutral check plus comments, so it informs rather than interrupts unless you choose otherwise.

The aim is a check that behaves like a good test suite: trusted enough that a red result means something, calibrated so it does not cry wolf. heygrc is in early access.