heygrc
Przewodnik

Konfiguracja heygrc: instalacja, konfiguracja jako kod, przegląd

Onboarding to jeden klik plus pojedyncze wywołanie API, które może wykonać Twój agent programistyczny. Oto cały proces, co robi każdy krok i dlaczego heygrc nigdy nie blokuje scalania samodzielnie.

zespół heygrc

heygrc przegląda pull requesty pod kątem ram compliance, których Twoja firma musi przestrzegać, bazując na kontekście Twojej firmy. Konfiguracja zajmuje około trzech minut i ma celową strukturę: zainstaluj aplikację GitHub raz, a następnie skonfiguruj wszystko inne jako kod za pomocą prostego API REST, co oznacza, że Twój agent programistyczny może zrobić większość pracy za Ciebie.

Ten przewodnik obejmuje cały proces od początku do końca: instalację, konfigurację, częstotliwość przeglądów oraz pytanie, które zadaje każdy inżynier: czy to narzędzie może zablokować moje scalanie. Dokładna specyfikacja API i ładunki znajdują się pod adresami https://docs.heygrc.com/docs/setup-with-an-agent i https://docs.heygrc.com/docs/api-reference; ta strona jest mapą.

Krok pierwszy: zainstaluj aplikację GitHub

Instalacja aplikacji GitHub jest zwykle działaniem właściciela organizacji lub konta, chociaż w niektórych organizacjach administrator repozytorium może ją zainstalować dla repozytoriów, którymi zarządza. W każdym razie jest to jedyny krok, którego nie może wykonać za Ciebie agent ani API. Z adresu github.com/apps/heygrc wybierz swoją organizację lub konto, zaznacz repozytoria, które chcesz poddać przeglądowi, i zainstaluj. Możesz zacząć od jednego repozytorium.

heygrc żąda minimalnych uprawnień: dostępu do kodu, metadanych i zgłoszeń, a także odczytu i zapisu w Checkach i Pull requestach, aby móc publikować recenzję i status. Nigdy nie potrzebuje dostępu do zapisu w Twoim kodzie i nigdy nie wprowadza commitów.

Krok drugi: skonfiguruj kontekst i ramy jako kod

To część, która sprawia, że heygrc jest narzędziem specjalistycznym, a nie ogólnym linterem. Opisujesz swoją firmę, to, co budujesz, dane, którymi zarządzasz, gdzie hostujesz, obowiązki, jakie na Tobie ciąży, wybierasz odpowiednie ramy, a ta konfiguracja jest zapisywana w heygrc za pomocą pojedynczego wywołania API. Ponieważ jest to zwykłe wywołanie REST, możesz powierzyć to zadanie swojemu agentowi programistycznemu: poleć Claude Code lub Cursor, aby skonfigurował heygrc dla Twojej organizacji z Twoim kontekstem i ramami, a on wykona wywołanie.

Profil firmy to swobodny kontekst, a im bardziej trafny, tym precyzyjniejsze są recenzje. heygrc wstrzykuje Twój profil i wiedzę dotyczącą wybranych ram do każdej recenzji, dzięki czemu zmiana w uwierzytelnianiu, obsłudze danych, logowaniu lub zależności jest sprawdzana względem Twoich specyficznych kontroli, a nie ogólnej listy kontrolnej. Możesz w każdej chwili odczytać konfigurację.

Krok trzeci: wybierz częstotliwość przeglądów

heygrc obsługuje trzy tryby przeglądów. W trybie auto (domyślnym) przegląda każdy pull request przy otwarciu, ponownym otwarciu lub dodaniu nowego commita. W trybie auto-once przegląda jedynie przy otwarciu lub ponownym otwarciu, nie przy każdym nowym commicie. W trybie mention-only pozostaje cichy, dopóki ktoś nie doda komentarza z komendą slash na pull request, co jest przydatne, gdy chcesz przeglądów na żądanie, a nie przy każdej zmianie.

Tryb ustawiasz dla organizacji, a możesz go nadpisać dla poszczególnych repozytoriów. Przeglądy na żądanie są dostępne tylko dla osób, które są właścicielami, członkami lub współpracownikami repozytorium, więc przypadkowy komentator nie może ich uruchomić.

Czy heygrc blokuje scalanie? Nie samodzielnie

heygrc publikuje swoją recenzję jako komentarze oraz status GitHub Checks, a ten status jest zawsze neutralny lub sukces, nigdy porażka z powodu znalezisk. Nigdy nie przesyła recenzji z żądaniem zmian. Dlatego domyślnie heygrc nie może zatrzymać scalania; informuje osoby i agenty dostarczające kod, a nie stoi między nimi a przyciskiem scalania.

Istnieje jedna ustawienie, które może to zmienić, i należy do Ciebie, a nie do heygrc. Jeśli Twoje repozytorium wymaga rozwiązania konwersacji przed scaleniem, to GitHub sam wymaga, aby wszystkie nierozwiązane wątki recenzji, w tym komentarze inline bota, zostały najpierw rozwiązane. heygrc pozostawia zakotwiczone komentarze inline na dokładnych liniach znalezisk, a te są wątkami do rozwiązania. W repozytorium z tą regułą włączoną musisz rozwiązać każde znalezisko przed scaleniem, co w przypadku przepływu compliance jest często pożądane: to lekka, zarejestrowana potwierdzenie, że zespół zauważył i uwzględnił wpływ kontroli. Jeśli nie chcesz tego, wyłącz regułę branch, a żadne komentarze recenzenta, czy to heygrc, czy człowieka, nie zablokują scalania.