Hovedpunkter
- Kode-skrivning er ikke det langsomme punkt længere. I 31 dage merged vores main repo 473 pull requests. 130 af dem krævede at nogen kom tilbage og mergede main ind i grenen, 239 merge commits i alt, og 238 af dem blev lavet af en person.
- PR’erne som havde brug for det tog en median på 44 timer fra åben til merge. De andre tog 2. Af de 60 PR’er som var åbne længere end tre dage, havde 51 brug for mindst ét merge af main.
- babysit-pr deler jobbet ved ét label:
LGTM, „looks good to me", som forfatteren tilføjer når arbejdet er færdigt. Før det, holder en skill agenten på PR’en indtil CI er grøn og alle review-boterne er besvaret. Efter det, holder en GitHub Actions-workflow PR’en mergeable indtil en person merger den, og tilføjerRTM, „ready to merge", når nogen anden end forfatteren godkender. - Workflowet merger aldrig, lukker aldrig og ændrer aldrig en linje som forfatteren skrev. En konflikt som det ikke kan løse omkring forfatterens kode går tilbage til forfatteren som
REWORK. - Skillen er offentlig, MIT-licenseret: babysit-pr-skill på GitHub , med watcher-scriptet og designet af workflowet. Workflowet selv er stadig i dry run på vores repo, og jeg forklarer nedenfor hvorfor.
Hvorfor bliver færdige pull requests inaktive?
Kode-skrivning holdt op med at være det langsomme punkt. Med architect-mønsteret og agenter som udfører det meste af typingen, tager vores repo omkring 13 commits om dagen ind i main. Det er godt for shipping og dårligt for hver åben pull request, fordi hver af disse commits kan sætte en PR i konflikt eller gøre dens CI rød.
Jeg hentede de seneste 31 dages merged PR’er for at se hvor tiden gik.
De 44 mod 2 er en korrelation, ikke en årsag. En PR som forbliver åben længere giver main mere tid til at bevæge sig under den, så det er mere sandsynligt at den skal merges. Men mergene selv er virkelig arbejde som nogen gjorde 239 gange i en måned. Fem mennesker lavede 238 af dem i hånden. En PR havde brug for otte merges af main over de syv dage den var åben.
Godkendelsen selv var hurtig. Når en PR fik sin første godkendelse, var median-tiden til merge nul timer. Ventetiden skete før det: forfatteren blev færdig, så PR’en sad der indtil en reviewer kom til den, og mens den sad der, bevægede main sig. Vi startede med at mærke færdige PR’er med LGTM den 20. oktober. De 20 som merged siden da ventede en median på 38 timer mellem LGTM og merge, og en ud af fire ventede mere end 78.
Det er gabet dette handler om. Ingen er hensynsløs her. Forfatteren tror de er færdige, revieweren har ikke åbnet den endnu, og grenen rådner ind i mellem.
Klar til at vokse din virksomhed?
Start din gratis prøveperiode i dag og se resultater inden for få dage.
Hvorfor ikke lukke inaktive pull requests med actions/stale?
Det sædvanlige svar på inaktive pull requests er actions/stale : en GitHub Action som tilføjer et inaktivt label til issues og pull requests efter et bestemt antal dage med inaktivitet, og lukker dem automatisk nogle dage senere hvis ikke nogen kommenterer eller pusher.
Det passer til en pull request som ingen arbejder på. Det gør ingenting for dem vi havde. Vores var færdigt arbejde som blev inaktivt mens det ventede på en reviewer, fordi main bevægede sig under dem. At lukke dem kaster arbejdet væk, og et inaktivt label fortæller forfatteren hvad de allerede ved. Hvad PR’en har brug for er nogen til at merge main ind, køre det røde CI-job igen og holde det grønt indtil en person godkender det. Så i stedet for at lukke inaktive pull requests, holder vi dem mergeable.
Sådan holder babysit-pr pull requests mergeable
Splittelsen følger hvem der venter. Før LGTM er forfatteren stadig på PR’en, normalt en agent-session, og skillen holder den session til at lave nyttigt arbejde i stedet for at erklære sejr når koden kompilerer. Efter LGTM er forfatteren gået videre, så arbejdet går til noget som ikke har brug for dem: et workflow som køres uanset om nogen ser på det.
LGTM står for „looks good to me". På de fleste teams siger en reviewer det om andres kode. Her sætter forfatteren det på deres egen PR som et label som betyder „Jeg er færdig, intet tilbage for mig at gøre". Det er en persons ord: agenten tilføjer det kun når det blev bedt om at overlade PR’en. Det label er opt-in til alt bagefter, og det er det som gør at en udvikler er komfortabel med at lade en bot pushe til deres gren.
Tilmeld dig vores nyhedsbrev
Få de seneste tips, trends og tilbud gratis.
Før LGTM: en Claude Code-skill bringer PR’en til klar
Skillen startede som babysit-pr-skillen i Theo Browne’s tstack
. Jeg beholdt dens watcher og dens kerneregler og ændrede hvor den stopper.
En watcher pr. pull request
pr-wait polinger en pull request og udskriver en linje pr. rigtig begivenhed: et check slog fejl, alle checks var færdige, nogen kommenterede eller reviewede, main bevægede sig under filer som denne PR rører, grenen kom bagud eller ind i konflikt, PR’en merged. I Claude Code køres det under Monitor-værktøjet, så hver linje vækker agenten en gang. En begivenhed som ikke kræver handling ender turen uden en besked. „Stadig venter" er ingen nyhed, og en agent som siger det halvtreds gange fylder sin egen kontekst med intet.
Sortér det røde CI-job før du rører kode
Der er fire slags rødt, og kun en er en kodereparation:
- PR’en brækkede det. Reparér det med den mindste ændring.
- Runderen flakede. Kør de fejlende jobs igen en gang. En anden fejl på samme head er ikke en flake.
- Main er rød. Reparer ikke main på nogen anden persons feature branch. Rapportér det og vent.
- Et processcheck er rødt, for eksempel linker PR’en ikke til et godkendt issue. Det er et skridt for en person.
Agenter uden tilsyn behandler alle fire som den første, og PR’en vokser en workaround til en test som er brudt på main.
Bevis et review-fund før du reparerer det
Et review-fund som agenten accepterer får et fejlende test først, derefter reparationen. Et fund den afviser får en skriftlig begrundelse. Dette er den samme regel som vores proven review-skill, og det er hvad der stopper review-boterne i at styre en PR efter volumen.
Hold PR’en størrelsen af sit mål
Review-løkker vokser en PR en billig-udseende reparation ad gangen: en sikring for et edge case som ingen rammer, en test til opførsel som ikke ændrede sig, en kompatibilitet shim. Skillen reparerer rigtige fejl i det tilsigtede tilfælde og afviser resten skriftligt. De værdifulde bliver til issues.
Klar er en checkliste
Alle gating CI jobs grønne på det nuværende head, alle review-boterne færdige på dette head, intet venter på en menneske, ingen uløst tråd, ingen konflikt. Når dette holder, rapporterer agenten det og stopper med at se.
Efter LGTM: en GitHub Actions-workflow løser merge-konflikter
Workflowet har to jobs.
Gaten beslutter hvad hver PR har brug for
Gaten er billig: ingen agent, ingen checkout af PR-kode. Den køres på hver push til main, hver CI-completion, hver label og review, og hver 30 minut, og en GraphQL-forespørgsel giver den hver åben LGTM PR. For hver en ren funktion beslutter hvad der skal gøres. Tilføj RTM hvis den er godkendt af nogen anden end forfatteren, grøn og konfliktfri. Lad den være hvis en review køres. Kør rødt CI igen en gang. Send en konflikt, eller CI som stadig er rød efter dens re-run, til fixeren.
Fixer-agenten merger main ind
Fixeren er et agent-job til en PR ved et head. Den merger main ind i grenen uden at committe, giver agenten de konflikt-filer og de fejl-logs, og lader den redigere kun de konflikt-filer og de filer PR’en allerede ændrer. Derefter stiller den ét spørgsmål.
Kan denne PR lande uden at ændre en linje som dens forfatter skrev?
Hvis ja, er dommen MODERNIZE. Agenten løser konflikten omkring forfatterens linjer, en validator tjekker resultatet og workflowet pusher et normalt merge-commit. Hvis nej, fordi main slettede funktionen PR’en redigerer eller PR’ens egen kode fejler CI, er dommen REWORK. Intet pushes, LGTM kommer af, og forfatteren får en kommentar med den mindste omskrivning. Hvis main allerede gør hvad PR’en gør, er dommen CLOSE, og en person lukker den.
Validatoren holder hver linje som forfatteren skrev
Validatoren er hvad der gør at reglen holder. Den afviser alle merges som mister en linje som PR’en tilføjede, eller en linje main tilføjede til en konflikt-fil. Den afviser redigeringer uden for de tilladt filer, tilbage liggende konflikt-markører og ændringer til CI eller sikkerhedsfiler. En agent som forsøger at „reparere" forfatterens kode slutter med et label som spørger efter en menneske, aldrig med en push. Workflowet pusher uden force, og kun hvis grenen ikke har bevæget sig siden forsøget startede. Et forsøg pr. head og base, to pr. head, tre kommentarer pr. PR pr. dag.
Det merger aldrig
RTM, „ready to merge", er gatens erklæring om at en PR har alt hvad den har brug for: forfatterens LGTM, en godkendelse fra nogen anden, grøn CI og ingen konflikt. En person laver mergingen. Det holdt designet lille, og det holdt argumentet om hvorvidt en bot skulle merge udenfor reviewet.
Hvad ændrer sig for forfatteren, revieweren og hvem der merger
Forfatteren siger færdig en gang. De kommer ikke tilbage tre dage senere for at merge main og vente på CI igen, og en agents PR rådner ikke fordi sessionen som åbnede den endte.
Revieweren åbner en PR som er grøn og mergeable på dagens main, så deres godkendelse er det sidste skridt og ikke starten på en anden runde.
Hvem der merger arbejder fra en liste. RTM forbliver på når gaten tilføjer det, og hvis main brækkeder PR’en efter det, reparerer workflowet det og labelen forbliver.
Og forfatteren holder kontrollen over deres kode. Det værste botten kan gøre til en gren er at tilføje et merge-commit som en validator har tjekket linje for linje.
Hvorfor vores gamle merge-konflikt-løser aldrig løb
Vi havde en konflikt-løser før denne. En detector fandt konflikt-PR’er og kommenterede på dem, og løseren løb når nogen tilføjede et label som bad den om det. I samme periode løb detektoren omkring 2.500 gange. Løseren løb nul gange.
Jeg tror ikke nogen var dovne. En udvikler som betragter en PR som færdig kommer ikke tilbage til den for at trykke på en knap. Automation som venter på at blive bedt om det bliver ikke bedt om. Derfor starter denne fra LGTM, det øjeblik forfatteren siger de er færdige, og gør resten uden dem.
Hvad virker ikke endnu?
To ting, og jeg ville hellere sige dem her end have dig find dem.
Workflowet er i dry run
Dens gate logger kun hvad den ville gøre indtil en repository-variabel siger andet. Før den kom så langt, fandt en review som kun holder findings den kan bevise med et fejlende test elve fejl i det. Et par er værdifulde at vide hvis du bygger din egen. GitHubs label-søgning halter, så en PR som den returnerer kan have mistet labelen for sekunder siden, og beslutningen skal tjekke live labels. En „dette head har allerede haft sin re-run" markør skrevet før re-run-kaldet lykkes lader et fejlende API-kald bruge headets eneste retry. Og en „mist ingen linje" tjek som ikke følger omdøbninger ser hver linje af en omdøbt fil som mistet.
Agent-runnerne var nede
Siden 19. oktober har ethvert job rettet mod vores agent-runnere fejlet at få en maskine: 406 aflyst, 24 stadig køet da jeg tjekked. Gaten køres andre steder og er fin, men fixeren har brug for en agent-runner, og en død en ser ud nøjagtigt som en stille dag. Intet slog fejl højt. Jobs køedes og blev derefter aflyst. Hvis du bygger dette, alert på fixer-runs som sidder køet.
Så tallene ovenfor er før-billedet. Lige nu har vi 27 åbne LGTM PR’er, 7 af dem med rødt CI og ingen med RTM. Det er tallene dette skulle ændre, og jeg vil rapportere hvad det gjorde.
Sådan installerer du babysit-pr-skillen
github.com/LivinTribunal/babysit-pr-skill har:
SKILL.md, skillen, med en kort „configure once" sektion til dine CI-workflows, review-boterne og process checks.scripts/pr-wait, watcheren. Den har brug for Python og en autentificeretgh.docs/after-lgtm.md, designet af after-LGTM-workflowet: labelerne, gaten, fixeren, reglen om at det aldrig ændrer forfatterens linjer, og de elve fejl.
Workflowet er et design i stedet for en fil at kopiere, fordi det kører mod en virksomheds labels, runnere og CI. Byg dit fra dokumentet, ship det i log-only mode, læs en dag af dets beslutninger, derefter tænd det.
Det parrer med architect-mønsteret , som beslutter hvem der skriver koden, og grain , som beslutter hvad koden ser ud til. babysit-pr er hvad der sker efter at enten af dem åbner pull request’en. Hvis du tuner agenten selv, dækker CLAUDE.md A/B-testen og kontekstgrænsningen som reducerede token-forbrug med 17% instruktionerne og omkostningerne.
