Zatwierdzanie i merge: co zawsze robi człowiek

Kto co może zrobić z merge requestem?

Granica jest prosta: agent przygotowuje zmianę do decyzji, a decyzję podejmuje człowiek. Poniższa tabela pokazuje ją czynność po czynności.

Czynność	Agent	Człowiek
Otwarcie merge requesta	tak, po zgodzie flagą `MONOLYNX_AUTOMR`	zawsze może
Naprawa czerwonego CI	tak, najwyżej dwie rundy	po dwóch nieudanych rundach
Rozwiązanie konfliktu	tak, przez wciągnięcie brancha docelowego	gdy konfliktu nie da się rozwiązać
Zatwierdzenie zmiany	nie	zawsze
Merge ticketu	tak, po Twojej zgodzie	zawsze może
Merge brancha sprintu do gałęzi głównej	nie	zawsze

1czynność, której agent nie wykona nigdy: zatwierdzenie

2rundy naprawy CI, zanim kolejka odda sprawę człowiekowi

1commit, z którym związana jest każda Twoja zgoda

Decyzje kolejki dla jednego merge requesta

Kolejka bierze pierwszy merge request i sprawdza go w stałej kolejności. Konflikt rozwiązuje sama. Czerwone CI naprawia sama, najwyżej dwa razy. Gdy brakuje zatwierdzenia, pyta człowieka. Po zgodzie merguje dokładnie ten commit, który człowiek zatwierdził.

flowchart TD
  A["Merge request"] --> B{"Konflikt?"}
  B -- "tak" --> C["Kolejka: wciąga branch docelowy"]
  B -- "nie" --> D{"CI zielone?"}
  D -- "nie" --> E["Kolejka: naprawa, do 2 rund"]
  D -- "tak" --> F{"Zatwierdzone?"}
  F -- "nie" --> G["Pytanie do człowieka"]
  G -- "tak" --> H["Merge tego commita"]
  F -- "tak" --> H

Jak zatwierdzić zmianę w kolejce?

Gdy merge request ma zielone CI i brakuje mu tylko zatwierdzenia, kolejka zatrzymuje się i pyta.

Pytanie kolejki o zatwierdzenie

> /monolynx:mr-queue

!42 SKL-12: eksport zamówień do CSV
CI: zielone | konflikt: brak | zatwierdzenie: brak

Approve !42 (SKL-12: eksport zamówień do CSV, SHA 4f2a9c1e)? tak / nie

MR-QUEUE: remaining=3 current=!42 verdict=needs_approval done=1

Otwórz merge request
Przeczytaj zmianę w GitLabie albo GitHubie, tak jak czytasz zmianę kolegi.
Sprawdź komentarze ticketu
Plan, raporty agentów i ocena krytyka mówią, co i dlaczego zostało zrobione.
Odpowiedz w rozmowie
"tak" zapisuje zgodę dla pokazanego commita. "nie" zostawia merge request w kolejce.
Poczekaj na następny tick
Kolejka policzy stan ponownie i zmerguje dokładnie ten commit.

Dlaczego zgoda jest związana z commitem?

Zatwierdzasz konkretną treść, a nie numer merge requesta. Gdy po Twojej zgodzie na branchu pojawi się nowy commit, zgoda przestaje obowiązywać. Dotyczy to także poprawki, którą zrobiła sama kolejka.

Zgoda w rozmowie a zatwierdzenie w GitLabie

To dwie różne rzeczy i warto wiedzieć, która jest potrzebna w Twoim projekcie.

Cecha	Zgoda w rozmowie	Zatwierdzenie w GitLabie albo GitHubie
Gdzie ją dajesz	w sesji z kolejką	w interfejsie merge requesta
Kto może ją dać	Ty	osoba z uprawnieniami w repozytorium
Co zapisuje	kolejka, razem z identyfikatorem commita	platforma, w historii merge requesta
Czy agent może ją dać	nie	nie
Kiedy wystarcza	gdy repozytorium nie wymaga formalnych zatwierdzeń	zawsze

Gdy repozytorium ma regułę wymagającą formalnych zatwierdzeń, sama zgoda w rozmowie nie wystarczy. Platforma odrzuci merge, a kolejka pokaże jej komunikat. Zatwierdź wtedy zmianę w interfejsie i uruchom kolejkę ponownie.

Jak działa merge i co zmienia flaga?

Po zgodzie kolejka wykonuje merge sama. Sposób pilnują dwie rzeczy: strażnik komend i jedna flaga.

Ustawienie	Co się dzieje przy merge
`MONOLYNX_AUTOMERGE` nieustawiona	strażnik komend pyta Cię o każde polecenie merge
`MONOLYNX_AUTOMERGE` ustawiona na `true`	kolejka merguje gotowy merge request bez dodatkowego pytania
sesja w tle	pytanie zamienia się w odmowę; bez flagi kolejka kończy turę linią z powodem

Metoda merge i to, co dzieje się po nim

Metodę wybiera zmienna MONOLYNX_MERGE_METHOD: merge (domyślnie), squash albo rebase.

Po merge do brancha sprintu kolejka od razu ustawia ticket jako Gotowy i bierze następny merge request. Po merge do domyślnego brancha repozytorium czeka najpierw na zielone CI tego brancha.

Kolejka sama nigdy nie robi na branchu ticketu wymuszonego pusha, rebase'u ani resetu. Konflikt rozwiązuje przez wciągnięcie brancha docelowego do brancha ticketu. Metoda rebase to co innego: wykonuje ją GitLab albo GitHub w chwili merge, bo tak ustawiłeś zmienną.

Co kolejka robi w tle, gdy nikt nie odpowiada?

Kolejka uruchomiona w skrypcie albo w sesji bez człowieka nie może zadać pytania. Zamiast czekać, kończy turę jedną linią z powodem.

Kolejka w tle czeka na człowieka

MR-QUEUE STOP: !42 czeka na approve
MR-QUEUE: remaining=3 current=!42 verdict=needs_approval done=1

Kolejka stoi wtedy na pierwszym merge requeście i nie przeskakuje do następnego. To celowe: merge requesty idą po kolei, bo każdy kolejny może zależeć od poprzedniego.

Merge sprintu do gałęzi głównej

Kolejka prowadzi merge requesty ticketów do brancha sprintu. Ostatni krok, czyli merge całego brancha sprintu do gałęzi głównej, zostaje przy człowieku. W projekcie z branchem develop to dwa merge: sprint do develop, potem develop do main.

Sprawdź tablicę
Wszystkie tickety sprintu mają status Gotowe.
Otwórz merge request sprintu
Z brancha sprintu do gałęzi głównej, tak jak każdy inny.
Poczekaj na pełne CI
To pierwszy moment, w którym wszystkie zmiany sprintu są testowane razem na docelowej gałęzi.
Zatwierdź i zmerguj
Sam albo z zespołem, zgodnie z zasadami repozytorium.
Zamknij sprint
Uruchom /monolynx:sprint-end.

Najczęstsze pytania

Czy mogę zatwierdzić kilka merge requestów naraz?

Nie w jednej odpowiedzi. Kolejka pyta o pierwszy, merguje go i dopiero wtedy przechodzi do następnego. Dzięki temu każdy następny jest sprawdzany na kodzie, który zawiera już poprzedni.

Co się stanie, gdy odpowiem "nie"?

Tick się kończy, a merge request zostaje pierwszy w kolejce. Kolejka zapyta ponownie przy następnym ticku. Żeby go pominąć, zamknij merge request albo usuń go z kolejki.

Czy agent może zatwierdzić własną zmianę?

Nie. Polecenia zatwierdzenia strażnik komend odmawia agentom pomocniczym, a sesję główną zawsze pyta. Żadna flaga tego nie wyłącza.

Zatwierdziłem zmianę, a kolejka pyta ponownie. Dlaczego?

Na branchu pojawił się nowy commit: poprawka CI, rozwiązanie konfliktu albo ręczna zmiana. Zgoda dotyczyła poprzedniego commita, więc przeczytaj różnicę i odpowiedz jeszcze raz.

Czy kolejka działa z GitHubem?

Tak. Obsługuje merge requesty GitLaba przez narzędzie glab i pull requesty GitHuba przez narzędzie gh. Zasady zatwierdzania są te same.

Słownik i następny krok

Zatwierdzenie: decyzja człowieka, że zmianę można zmergować; po angielsku approve
Zgoda w rozmowie: zatwierdzenie wyrażone w sesji z kolejką, zapisane razem z identyfikatorem commita
Identyfikator commita: skrót jednoznacznie wskazujący wersję kodu; po angielsku SHA
Kolejka: komenda mr-queue, która prowadzi merge requesty do merge jeden po drugim
Strażnik komend: hook pluginu, który pyta albo odmawia przed poleceniem merge i zatwierdzenia
Branch docelowy: branch, do którego trafia merge request

Pełny opis kolejki znajdziesz we wpisie Jak działa /monolynx:mr-queue. Kiedy ticket dostaje status Gotowe, wyjaśnia wpis Statusy ticketu w Monolynx. Cały sprint od planu do zamknięcia prowadzi Sprint z Monolynx krok po kroku.

Chcesz zobaczyć przebieg pracy agentów nad ticketem, zanim zatwierdzisz zmianę?

Zobacz moduł Pipelines w Monolynx