Przeglądy pull requestów
Większość incydentów zaczyna się od zmiany. Polylane przegląda każdy pull request w połączonym repozytorium na tle zasobów produkcyjnych, na które jest wdrażany, i publikuje jeden komentarz, który mówi pass albo fail.
Co robi
Agent czyta diff oraz bieżące metryki, logi i otwarte problemy zasobów, na które repozytorium jest wdrażane, a potem decyduje, czy zmiana może zaszkodzić produkcji. Dostajesz jeden komentarz w pull requeście, opcjonalny check Polylane production impact i wątek w konsoli z pełną analizą.
Jak to działa
- Otwarcie pull requesta do gałęzi domyślnej, push do niego albo oznaczenie go jako gotowego do przeglądu rozpoczyna przegląd jego najnowszego commita. Drafty nie są przeglądane.
- Późniejszy push zastępuje trwający przegląd, więc oceniany jest tylko najnowszy commit.
- Zmiany dotykające wyłącznie dokumentacji, testów albo plików CI przechodzą bez dochodzenia.
- Polylane podąża krawędziami wdrożeń repozytorium do jego zasobów produkcyjnych, a gdy ich nie ma, przegląda na tle kont chmurowych obszaru roboczego jako całości.
- Agent prowadzi dochodzenie w wątku i zapisuje werdykt
passalbofail. - Jeden komentarz na pull request jest edytowany przy każdym przeglądzie. Fail brzmi Hold this merge z poziomem wpływu i ustaleniem; pass brzmi Production impact unlikely albo mówi, czy poprawka wykrytego problemu ma go rozwiązać. Gdy późniejszy push odpowiada na zastrzeżenie, komentarz wraca do pass i o tym informuje.
Agent może też zasugerować ulepszenia obserwowalności, jako jeden zbiorczy przegląd z komentarzami-sugestiami albo jako pull request typu stacked. Nigdy nie wpływają one na werdykt.
Reagowanie na przegląd
Wspomnij @polylane w komentarzu w pull requeście, a Polylane odpowie w tej samej rozmowie; osoby niebędące członkami otrzymują zamiast tego informację o dostępie.
| O co prosisz | Co się dzieje |
|---|---|
| Pytanie | Agent odpowiada z wątku przeglądu, mając dowody przed sobą. |
| Ponowne spojrzenie | Agent przegląda ponownie najnowszy push i weryfikuje werdykt. |
| Poprawkę | Polylane rozpoczyna przebieg naprawy i otwiera pull request typu stacked do gałęzi pull requesta, podlinkowany z komentarza. |
Karta Changes repozytorium w konsoli wymienia każdy przegląd. Fail oferuje Fix with Polylane, które rozpoczyna ten sam przebieg naprawy, oraz Dismiss, gdy zastrzeżenie nie ma zastosowania: pull request nadal jest przeglądany, ale nie dostaje kolejnych komentarzy, dopóki nie użyjesz Restore.
| Status | Opis |
|---|---|
| In review | Polylane przegląda najnowszy push. |
| Flagged | Przegląd znalazł zastrzeżenie dotyczące produkcji. |
| Passed | Nie znaleziono zastrzeżeń dotyczących produkcji. |
| Resolved | Późniejszy push odpowiedział na zastrzeżenia. |
| Dismissed | Członek odrzucił przegląd; pull request nie dostaje kolejnych komentarzy. |
Konfiguracja
Przeglądy są włączone dla każdego połączonego repozytorium. Settings > Pull request reviews wyłącza je w całym obszarze roboczym i określa, czy wątki przeglądów są udostępniane osobom oglądającym pull request. W Settings > Repositories karta Settings repozytorium dodaje trzy pola.
| Pole | Opis |
|---|---|
| Review pull requests for production impact | Wyłącza przeglądy tylko dla tego repozytorium. |
| Pull request review instructions | Dowolny tekst, który agent czyta przy każdym przeglądzie: ścieżki krytyczne dla wdrożenia albo kwestie, którymi zajmują się już inne bramki. |
| Block merging on production concerns | Publikuje check Polylane production impact na każdym przeglądanym pull requeście; kończy się on niepowodzeniem przy zastrzeżeniu. Domyślnie włączone. Wymagaj go w ochronie gałęzi, żeby zablokować scalanie. |
Check kończy się też na commitach kolejki scalania, ponieważ pull request został przejrzany, zanim do niej trafił. Werdykt fail może wysłać e-mail Production Concern Found, domyślnie wyłączony w Powiadomieniach.
Uwagi o planach
Każdy plan obejmuje miesięczną liczbę przeglądów pull requestów; limit planu Free jest podany na stronie Rozliczenia i zużycie, a członkowie otrzymują e-mail, gdy się kończy. Po wyczerpaniu limitu konsola zapisuje pull request jako Production impact not verified i nic nie jest publikowane na GitHub.
Powiązane
- Repozytoria: połącz repozytorium i powiąż jego zasoby.
- Przebiegi naprawy: jak wątek przeglądu dochodzi do werdyktu.
- Autofix: pull requesty, które otwiera przebieg naprawy.
- Powiadomienia: e-mail, który może wysłać nieudany przegląd.
Problemy
Każdy problem, który Polylane wykryje albo otrzyma z twojego alertowania, staje się jednym problemem, nad którym pracuje jeden przebieg naprawy, a jego wątek opowiada całą historię.
Advisories
Rekomendacje dla pojedynczych zasobów dotyczące błędnej konfiguracji, ryzyk dla odporności i luk w obserwowalności, każda z poprawką, którą możesz przekazać agentowi.