GitHub zapisze każde odrzucenie wyniku Code Quality — audyt pokaże kto i kiedy

W komunikacie GitHub z 13 października 2026 r. ogłoszono, że dzienniki audytu organizacji i przedsiębiorstw zapisują ręczne odrzucenia oraz ponowne otwarcia ustaleń Code Quality z listy zaległości repozytorium. Wpis wskazuje, kto zainicjował działanie, kiedy to nastąpiło oraz którego repozytorium i których ustaleń dotyczyło. Funkcja jest ogólnie dostępna w GitHub Team i GitHub Enterprise Cloud, także w środowiskach z rezydencją danych.

Administrator może więc odtworzyć decyzję, nawet jeśli bieżący stan ustalenia później się zmieni. Jak zauważa iMasters, nowe zdarzenia nie wymagają podania uzasadnienia odrzucenia: odpowiadają na pytanie, kto wykonał działanie, lecz sam powód wymaga osobnego zapisu. Ma to znaczenie przy przeglądzie decyzji, które pozostawiły ustalenie poza listą otwartych spraw.

Jakie decyzje trafiają do dziennika

Ręczne odrzucenie jednego lub kilku ustaleń z listy zaległości zapisuje zdarzenie repo.code_quality_findings_dismissed. Ponowne otwarcie takich ustaleń zapisuje repo.code_quality_findings_reopened. Wpis obejmuje wykonawcę, czas, repozytorium, regułę oraz identyfikatory i liczbę ustaleń objętych operacją. Jeśli jedna operacja dotyczy kilku pozycji, ich liczba we wpisie nie oznacza kilku osobnych decyzji.

Ustalenia Code Quality mogą pojawiać się zarówno na liście zaległości gałęzi domyślnej, jak i w pull requestach. Opis nowych zdarzeń wskazuje jednak wprost ręczne działania dotyczące listy zaległości. Zdarzenia wykonanego bezpośrednio w pull requeście nie należy zatem automatycznie utożsamiać z opisanym wpisem audytu; zakres takiego działania trzeba ocenić na podstawie rzeczywiście dostępnych danych.

Repozytorium z włączonym Code Quality nie wymaga dodatkowej konfiguracji, aby nowe zdarzenia powstawały. Do ich przeglądania potrzebny jest dostęp do dziennika audytu organizacji lub przedsiębiorstwa. W GitHub Enterprise Cloud wpisy można również pobrać przez API dziennika audytu; nowa funkcja nie jest dostępna w GitHub Enterprise Server. Ta różnica ma znaczenie w organizacjach korzystających równolegle z usług chmurowych i własnej instalacji.

Filtry dla odrzuceń i ponownych otwarć

Do przeglądu odrzuceń służy filtr action:repo.code_quality_findings_dismissed, a do przeglądu ponownych otwarć — action:repo.code_quality_findings_reopened. Rozdzielenie zapytań pozwala zachować kolejność działań: najpierw ustalić, które pozycje odrzucono, a następnie sprawdzić, czy te same pozycje przywrócono. Wyniki należy porównywać po repozytorium i identyfikatorze ustalenia, a nie tylko po nazwie reguły, która może występować w wielu miejscach.

Filtr repo:ORG/REPO zawęża przegląd do wybranego repozytorium; ORG i REPO są tu nazwami zastępczymi. Można dołączyć także kwalifikator created, aby ograniczyć okres. Przykładowe, umowne zapytanie action:repo.code_quality_findings_dismissed repo:ORG/REPO created:2026-10-14..2026-10-15 pokazuje składnię dla wybranego okna czasowego, a nie rzeczywiste zdarzenia z tych dni. Analogiczne zapytanie dla ponownych otwarć wymaga zmiany wartości action.

Przy operacji obejmującej wiele ustaleń pojedynczy wiersz wyników może reprezentować kilka identyfikatorów. Dlatego zestawienie audytowe powinno zachować pełną listę objętych pozycji, liczbę podaną we wpisie, regułę oraz czas działania. Taki zapis pozwala później odróżnić pojedynczą decyzję zbiorczą od serii odrębnych odrzuceń i przypisać każdej pozycji właściwy przebieg zmian.

Połączenie zdarzenia z ustaleniem w REST API

Dokumentacja REST API Code Quality opisuje listę dostępną pod GET /repos/{owner}/{repo}/code-quality/findings. Parametr state pozwala pobrać ustalenia w stanie open albo dismissed. Odpowiedź zawiera między innymi pole number, bieżący stan, identyfikator i wagę reguły oraz położenie ustalenia w pliku. Osobny endpoint zakończony /findings/{finding_number} zwraca pojedynczą pozycję.

Schemat korelacji zaczyna się od repozytorium podanego w zdarzeniu audytowym. Następnie dla każdego identyfikatora z tego zdarzenia trzeba sprawdzić, czy odpowiada on wartości number w rekordzie zwróconym przez API, i porównać regułę. Dopiero potwierdzona para repozytorium i numer ustalenia daje podstawę do połączenia historii decyzji z jego bieżącym rekordem. GitHub nie podaje w ogłoszeniu nazw pól przechowujących identyfikatory w nowych zdarzeniach, więc zgodności z number nie można zakładać bez obejrzenia rzeczywistego wpisu.

Stan zwrócony przez API opisuje ustalenie w chwili pobrania, podczas gdy dziennik audytu przechowuje informację o wcześniejszym działaniu. Po odrzuceniu i późniejszym ponownym otwarciu ustalenie może być dziś oznaczone jako open. Brak pozycji na liście state=dismissed nie przekreśla zatem historycznego odrzucenia. Pełny przebieg wymaga uporządkowania obu rodzajów zdarzeń według czasu i odniesienia ich do tej samej pozycji.

Do odczytu ustaleń za pomocą tokenu o szczegółowych uprawnieniach potrzebne jest uprawnienie „Code quality” na poziomie odczytu w repozytorium. Lista wyników jest stronicowana, więc pobranie jednej strony nie musi dać kompletnego obrazu odrzuconych pozycji. W eksporcie warto zachować także techniczny kontekst ustalenia: regułę, lokalizację w pliku i stan z chwili pobrania. Pozwala to odróżnić dawną decyzję od późniejszej zmiany kodu lub stanu ustalenia.

Uzasadnienie i przegląd ręcznych decyzji

Nowy wpis dokumentuje działanie, ale nie rozstrzyga, czy odrzucenie było zasadne. Minimalna polityka zespołu może wymagać zapisania powodu każdej ręcznej decyzji wraz z repozytorium, numerem ustalenia i odnośnikiem do zgłoszenia lub dyskusji, w której ją oceniono. Jest to reguła przyjęta przez organizację, a nie obowiązkowe pole nowych zdarzeń. Powód powinien być na tyle konkretny, by późniejszy przegląd mógł odnieść go do danej reguły i miejsca w kodzie.

Okresowy przegląd może zestawiać odrzucone ustalenia z historią zdarzeń i zapisanymi powodami. Szczególnej uwagi wymagają operacje zbiorcze, wielokrotne decyzje dotyczące tej samej pozycji oraz ustalenia ponownie otwarte. Dla każdej z nich liczy się chronologia: kto odrzucił pozycję, jakie uzasadnienie wtedy zapisano i czy późniejsze ponowne otwarcie zmieniło ocenę. Sama liczba aktualnie odrzuconych pozycji nie pokazuje takiego przebiegu.

Organizacja powinna ustalić okres przechowywania eksportów audytu i powiązanych uzasadnień oraz ograniczyć dostęp do nich do osób prowadzących przegląd. Przechowanie identyfikatorów, czasu i powodów razem ma praktyczne znaczenie: gdy starszy wpis przestanie być dostępny w dzienniku, bieżąca lista ustaleń nie odtworzy już tego, kto wcześniej podjął ręczną decyzję.

Przeczytaj także:

• AI odrzuciło kandydaturę? Możesz żądać wyjaśnienia decyzji
• Claude Code czy Codex? Ten sam wynik może kosztować o 40% mniej
• GitHub Actions czy CircleCI? Minuta kosztuje podobnie, kolejka już nie