Jak działa /monolynx:mr-queue: kolejka merge, która sama pilnuje CI

Po co kolejka merge, skoro MR można kliknąć ręcznie?

Ręczne mergowanie działa przy jednym MR dziennie. Gdy agenci oddają kilka zmian naraz, zaczyna się pilnowanie: ten ma konflikt po poprzednim merge, tamten czerwone CI, trzeci czeka na approve, a po każdym merge trzeba sprawdzić, czy branch docelowy nadal jest zielony. To praca, w której człowiek głównie czeka i odświeża stronę.

Skill mr-queue przejmuje czekanie. Trzyma listę MR i PR w ustalonej kolejności i przy każdym uruchomieniu przesuwa pierwszy z nich o jeden krok w stronę merge. Działa z GitLabem przez glab i z GitHubem przez gh.

# zalecane: pętla co 10 minut, kolejka układa się sama
/loop 10m /monolynx:mr-queue

# jeden tick ręcznie
/monolynx:mr-queue

# własna kolejność merge
/monolynx:mr-queue !142 !139 !145

Dlaczego zalecamy pętlę co 10 minut?

Jedno uruchomienie skilla to jeden tick, a pełne przejście MR przez kolejkę wymaga kilku ticków: merge brancha docelowego, czekanie na nowe CI, merge, czekanie na CI brancha docelowego. Pętla jest celowo poza skillem. Skill robi krok i kończy turę, a o rytmie decyduje /loop.

/loop 10m /monolynx:mr-queue

Dziesięć minut to rytm dobrany do tego, na co kolejka czeka najczęściej, czyli do rundy CI. U nas pełna runda lintu i testów trwa kilkanaście do dwudziestu minut, więc tick co 10 minut zauważa wynik niedługo po jego pojawieniu się, a nie odpytuje serwera co chwilę bez powodu. Większość ticków kończy się werdyktem wait i niczego nie zmienia.

Pętla ma jeszcze jedną zaletę: kolejka sama rośnie. Przy każdym ticku skill dopisuje na koniec otwarte MR, których jeszcze w niej nie ma. Nowa zmiana oddana przez agenta w trakcie dnia trafia do kolejki bez żadnej komendy. Dotyczy to każdego otwartego merge requesta, także merge requesta całego sprintu do gałęzi głównej. Trzymaj go jako draft, dopóki tickety nie są zmergowane: drafty kolejka pomija.

Co dzieje się w jednym ticku?

1. Kontrola wstępna

   Skill sprawdza repozytorium, logowanie glab albo gh i spójność konfiguracji brancha docelowego.

2. Kolejka

   Bez argumentów układa ją sam z otwartych MR; z argumentami przyjmuje podaną kolejność.

3. Pierwszy niezmergowany element

   Reszta kolejki czeka, bo kolejność jest święta.

4. Werdykt

   Skrypt mr_queue_state.py liczy go z JSON-a dostawcy.

5. Jedno działanie

   Rozwiązanie konfliktu, poprawka CI, pytanie o approve albo merge.

6. Raport i linia statusu

   Ostatnia linia odpowiedzi ma zamrożony format, który czytają pętla i inne narzędzia.

flowchart TD
  A[Pierwszy MR w kolejce] --> B{Konflikt?}
  B -->|tak| C[Anuluj pipeline MR i zmerguj branch docelowy]
  B -->|nie| D{CI}
  D -->|w toku| E[wait: koniec ticka]
  D -->|czerwone| F[Poprawka w tymczasowym worktree]
  D -->|zielone| G{Approve?}
  G -->|brak| H[Pytanie do człowieka]
  G -->|jest| I[Merge z blokadą na SHA]
  C --> J[Koniec ticka]
  F --> J
  H --> J
  I --> J

Jak skill układa kolejkę?

Bez argumentów skill pobiera listę otwartych MR i układa je od najstarszego. MR oparty o branch innego otwartego MR idzie zaraz po nim. Drafty i zmiany oparte o draft są pomijane, z powodem w raporcie. Kolejkę przyjmuje bez pytania, a inną kolejność można podać w każdej chwili jako argumenty: !iid dla GitLaba, #numer dla GitHuba albo pełny adres.

Plik kolejki leży we wspólnym katalogu gita, więc jest jeden dla głównego checkoutu i wszystkich worktree repozytorium.

Jakie werdykty może dać tick?

Dlaczego konflikt wygrywa z CI?

CI na branchu, który koliduje z branchem docelowym, nie da mergowalnego wyniku, a runda trwa i zajmuje runner innym zmianom. Dlatego przy konflikcie tick anuluje trwający pipeline MR i od razu merguje branch docelowy w tymczasowym, odłączonym worktree. Konflikty w plikach rozstrzyga subagent na modelu opus, bo musi pogodzić dwie intencje, a nie tylko poprawić składnię. Gdy intencje są sprzeczne, subagent przerywa, a pozycja czeka na człowieka.

Jak wygląda poprawka czerwonego CI?

Tick czyta ogon logu czerwonych jobów, tworzy odłączony worktree na aktualnym HEAD brancha MR i zleca poprawkę subagentowi na modelu sonnet. Commit i push robi główna sesja, zwykłym pushem na branch MR. Potem worktree znika, a nowy pipeline oceni następny tick.

Co wolno automatowi, a co zostaje dla człowieka?

Skill pyta tylko o decyzje, które należą do człowieka: approve, merge bez włączonej zmiennej MONOLYNX_AUTOMERGE i push do cudzego brancha. Approve dany w rozmowie wiąże się z konkretnym SHA. Każdy nowy commit na branchu, także poprawka zrobiona przez sam skill, wymaga nowego zatwierdzenia.

Gdy tick trafia na stan wymagający człowieka, nie pyta "co dalej?". Kończy się raportem z linią Potrzebne:, która mówi, co dokładnie zrobić i jaką komendą wrócić do kolejki. Po działaniu człowieka kolejka rusza sama przy następnym ticku.

Co się dzieje po merge?

Tor po merge zależy od brancha docelowego i wybiera go skrypt, nie model.

Na koniec każdego ticka skill wypisuje linię statusu:

MR-QUEUE: remaining=3 current=!142 verdict=ready done=2

Najczęstsze pytania

Słownik i następny krok

Tick

jedno uruchomienie skilla: odczyt stanu, jedno działanie, raport

Werdykt

stan MR policzony przez skrypt z danych GitLaba albo GitHuba

Branch integracyjny

branch docelowy inny niż domyślny branch repozytorium, na przykład branch sprintu

Blokada na SHA

merge przechodzi tylko wtedy, gdy HEAD brancha jest tym commitem, który tick ocenił

Raport "Potrzebne"

zakończenie ticka z konkretnym działaniem dla człowieka zamiast pytania

Idempotentny

powtórzony daje ten sam stan, bez zdublowanych skutków

Kolejka merge domyka obieg, który zaczyna skill work, prowadzący ticket od planu do merge requesta, a kończy skill sprint-end, zamykający sprint i aktualizujący wiki.

Granicę między kolejką a człowiekiem, czyli zgodę związaną z commitem i merge, opisuje wpis Zatwierdzanie i merge: co zawsze robi człowiek. Kiedy ticket po merge dostaje status Gotowe, wyjaśnia wpis Statusy ticketu w Monolynx.