heygrc esegue la revisione delle pull request rispetto ai framework di conformità che la tua azienda deve rispettare, basandosi sul contesto specifico della tua organizzazione. La configurazione richiede circa tre minuti e ha una struttura deliberata: installa l'app GitHub una volta, poi configura tutto il resto as code tramite una piccola API REST, il che significa che il tuo agente di codifica può fare la maggior parte del lavoro per te.
Questa guida copre l'intero flusso, dall'installazione alla configurazione, alla frequenza delle revisioni, oltre alla domanda che ogni sviluppatore si pone per primo: può questo strumento bloccare i miei merge? Il contratto API esatto e i payload sono disponibili su https://docs.heygrc.com/docs/setup-with-an-agent e https://docs.heygrc.com/docs/api-reference; questa pagina funge da mappa.
Passo uno: installa l'app GitHub
L'installazione di un'app GitHub è solitamente un'azione riservata al proprietario dell'organizzazione o dell'account, anche se in alcune organizzazioni un amministratore del repository può installarla per i repository che gestisce. In ogni caso, questo è l'unico passaggio che nessun agente o API può fare al posto tuo. Da github.com/apps/heygrc, seleziona la tua organizzazione o account, scegli i repository che vuoi sottoporre a revisione e installa. Puoi iniziare con un singolo repository.
heygrc richiede solo le autorizzazioni minime necessarie: accesso in lettura al codice, ai metadati e alle issue, e accesso in lettura e scrittura ai Check e alle Pull request, in modo da poter pubblicare una revisione e uno stato. Non richiede mai l'accesso in scrittura al codice e non esegue mai push di commit.
Passo due: configura il contesto e i framework as code
Questa è la parte che rende heygrc uno specialista piuttosto che un linter generico. Descrivi la tua azienda, cosa costruisci, i dati che gestisci, dove li ospiti, gli obblighi a cui sei soggetto, e selezioni i framework applicabili. Questa configurazione viene scritta in heygrc con una singola chiamata API. Poiché si tratta di una semplice chiamata REST, puoi affidare il compito al tuo agente di codifica: chiedi a Claude Code o Cursor di configurare heygrc per la tua organizzazione con il tuo contesto e i tuoi framework, e lui esegue la chiamata.
Il profilo aziendale è un contesto in formato libero e, più è pertinente, più precise saranno le revisioni. heygrc integra il tuo profilo e le conoscenze relative ai framework selezionati in ogni revisione, in modo che una modifica all'autenticazione, alla gestione dei dati, al logging o a una dipendenza venga valutata rispetto ai tuoi controlli specifici piuttosto che a un elenco di controllo generico. Puoi leggere la configurazione in qualsiasi momento.
Passo tre: scegli la frequenza delle revisioni
heygrc supporta tre modalità di revisione. In modalità auto, quella predefinita, esegue la revisione di ogni pull request quando viene aperta, riaperta o quando viene eseguito un push. In modalità auto-once, esegue la revisione solo all'apertura o alla riapertura, non per ogni nuovo commit. In modalità mention-only, rimane silenzioso fino a quando qualcuno commenta un comando slash sulla pull request, utile quando si desiderano revisioni su richiesta piuttosto che per ogni modifica.
Imposti la modalità per organizzazione e puoi sovrascriverla per repository. Le revisioni su richiesta sono limitate alle persone che sono proprietari, membri o collaboratori del repository, quindi un commentatore occasionale non può avviarle.
heygrc blocca i tuoi merge? Non autonomamente
heygrc pubblica la sua revisione come commenti più uno stato GitHub Checks, e tale stato è sempre neutro o di successo, mai un errore in caso di riscontri. Non invia mai una revisione con richiesta di modifiche. Quindi, per impostazione predefinita, heygrc non può bloccare un merge; informerà le persone e gli agenti che spediscono il codice piuttosto che porsi tra loro e il pulsante di merge.
Esiste un'impostazione che può cambiare questo, e appartiene a te, non a heygrc. Se il tuo repository richiede la risoluzione delle conversazioni prima del merge, GitHub stesso richiede che ogni thread di revisione non risolto, inclusi i commenti in linea di un bot, venga risolto prima. heygrc lascia commenti in linea ancorati alle righe esatte di un riscontro, e questi sono thread risolvibili. In un repository con questa regola attiva, risolvi ogni riscontro prima del merge, il che per un flusso di lavoro di conformità è spesso auspicabile: rappresenta un riconoscimento leggero e registrato che il team ha visto e affrontato l'impatto del controllo. Se non desideri questo, disattiva la regola del branch e i commenti di nessun revisore, sia di heygrc che umani, bloccheranno un merge.