Kľúčové poznatky
- Písanie kódu už nie je pomalá časť. Za 31 dní naša hlavná úložisko zlúčilo 473 pull requestov. 130 z nich potrebovalo, aby sa niekto vrátil a zlúčil main do vetvy, celkovo 239 merge commitov, a 238 z nich bolo vytvoreného osobou.
- Pull requesty, ktoré to potrebovali, trvali medián 44 hodín od otvorenia do zlúčenia. Tie, ktoré to nepotrebovali, trvali 2 hodiny. Z 60 PR, ktoré zostali otvorené dlhšie ako tri dni, 51 potrebovalo aspoň jedno zlúčenie mainu.
- babysit-pr rozdeľuje úlohu na jednu značku:
LGTM, „vyzerá mi to dobre", ktorú autor pridá keď je práca hotová. Pred tým zručnosť udržiava agenta na PR, kým nie je CI zelená a každý review bot je odpoveď. Po tom pracovný postup GitHub Actions udržiava PR zlučiteľný, kým ho osoba nezlúči, a pridávaRTM, „pripravené na zlúčenie", keď niekto iný ako autor schváli. - Pracovný postup nikdy nezlučuje, nikdy nezatvára a nikdy nezmení riadok, ktorý napísal autor. Konflikt, ktorý nemôže vyriešiť okolo kódu autora, sa vracia autorovi ako
REWORK. - Zručnosť je verejná, s licenciou MIT: babysit-pr-skill na GitHub , s skriptom sledovateľa a návrhom pracovného postupu. Samotný pracovný postup je stále v suchom spustení na našom úložisku a vysvetľujem nižšie prečo.
Prečo sa hotové pull requesty zastarávajú?
Písanie kódu už nie je pomalá časť. S architektúrnym vzorom a agentmi robiaci väčšinu písania, naše úložisko trvá asi 13 commitov denne do mainu. To je dobré pre shipping a zlé pre každý otvorený pull request, pretože každý z týchto commitov môže dať PR do konfliktu alebo mu zčervenať CI.
Vytiaholm posledných 31 dní zlúčených PR, aby som videl, kam sa čas stratil.
44 oproti 2 je korelácia, nie príčina. PR, ktorý zostáva dlhšie otvorený, dáva mainowi viac času na to, aby sa posunul pod ním, takže je pravdepodobnejšie, že bude potrebovať zlúčenie. Ale zlúčenia samy sú skutočná práca, ktorú niekto vykonal 239-krát za mesiac. Päť ľudí vyrobilo 238 z nich ručne. Jeden PR potreboval osem zlúčení mainu počas siedmich dní, keď bol otvorený.
Samotné schválenie bolo rýchle. Keď PR dostalo svoje prvé schválenie, medián času do zlúčenia bol nula hodín. Čakanie sa stalo pred tým: autor skončil, potom PR čakal, kým sa recenzent dostal k nemu, a počas čakania sa main posunul. Začali sme označovať hotové PR LGTM 20. októbra. 20, ktorí sa zlúčili odvtedy, čakali medián 38 hodín medzi LGTM a zlúčením, a jeden zo štyroch čakal viac ako 78 hodín.
To je medzera, na ktorú je. Nikto tu nie je bezstarostný. Autor si myslí, že je hotový, recenzent si ho ešte neotvoril, a vetva sa v priebehu rozkláda.
Pripravení rozšíriť svoje podnikanie?
Začnite svoju 30-dňovú skúšobnú verziu ešte dnes a vidzte výsledky behom pár dní.
Prečo nie zatvoriť zastarané pull requesty s actions/stale?
Obvyklá odpoveď na zastarané pull requesty je actions/stale : akcia GitHub, ktorá po určitom počte dní nečinnosti pridáva značku zastarané na problémy a pull requesty a automaticky ich zatvára o pár dní neskôr, pokiaľ si niekto nekomentuje alebo nevytlačí.
To sa hodí na pull request, na ktorom nikto nepracuje. Ničím to nerobi pre tie, ktoré sme mali. Tie naše boli hotová práca, ktorá sa zastarala počas čakania na recenzenta, pretože main sa pod nimi posunul. Ich uzavretie vyhodí prácu, a značka zastarané hovorí autorovi, čo už vedia. Čo PR potrebuje, je aby niekto zlúčil main, znova spustil červenú úlohu CI a udržoval ju zelenú, kým ju osoba neschváli. Takže namiesto uzatvárania zastaraných pull requestov, ich udržiavame zlučiteľné.
Ako babysit-pr udržiava pull requesty zlučiteľné
Rozdelenie nasleduje, kto čaká. Pred LGTM je autor stále na PR, zvyčajne relácia agenta, a zručnosť udržiava tú reláciu užitočnú prácu namiesto toho, aby vyhlasoval, že je víťazstvo, keď sa kód kompiluje. Po LGTM sa autor presunul ďalej, takže práca ide na niečo, čo ich nepotrebuje: pracovný postup, ktorý beží bez ohľadu na to, či sa na neho niekto pozerá.
LGTM znamená „vyzerá mi to dobre". Na väčšine tímov to o kóde niekoho iného hovorí recenzent. Tu to autor umiestnuje na ich vlastný PR ako značku, ktorá znamená „Som hotový, nič mi ľavá urobiť". Je to slovo osoby: agent ju pridá len keď mu bolo povedané, aby PR predal. Táto značka je opt-in pre všetko po nej, a to je vec, ktorá robí vývojára komfortného tým, že nechá bota vytláčať do jeho vetvy.
Prihláste sa na newsletter
Získajte najnovšie tipy, trendy a ponuky zadarmo.
Pred LGTM: zručnosť Claude Code posúva PR do stavu pripravenosti
Zručnosť sa začala ako zručnosť babysit-pr v Theovom tstack
. Udržal som jeho sledovateľa a jeho základné pravidlá a zmenil som, kde sa zastaví.
Jeden sledovateľ na pull request
pr-wait hlasuje jeden pull request a tlačí jeden riadok na skutočnú udalosť: kontrola zlyhala, všetky kontroly skončili, niekto komentoval alebo recenzoval, main sa posunul pod súbory, ktoré tento PR dotýka, vetva sa dostala za alebo do konfliktu, PR sa zlúčil. V Claude Code beží pod nástrojom Monitor, takže každý riadok prebúdi agenta raz. Udalosť, ktorá nepotrebuje žiadne opatrenie, skončí otočenie bez správy. „Stále čakanie" nie je správa, a agent, ktorý to povie päťdesiaťkrát, vyplní svoj vlastný kontext ničím.
Zoraďte červenú úlohu CI pred dotykom kódu
Existujú štyri druhy červenej, a len jedna je oprava kódu:
- PR ju zlomil. Opraviť ju najmenšou zmenou.
- Spúšťač sa posunul. Znova spustiť zlyhané úlohy raz. Druhé zlyhanie na rovnakej hlave nie je posun.
- Main je červený. Neopravte main na vetve niečích funkcií. Nahláste to a čakajte.
- Kontrola procesu je červená, napríklad PR nie je prepojený na schválený problém. To je krok pre osobu.
Agenti ponechaní sami si myslia všechni štyria ako prvý, a PR rastie workaround na test, ktorý je zlomený na main.
Preukážte nález recenzie pred jeho opravou
Nález recenzie, ktorý agent akceptuje, dostane najskôr zlyhávajúci test, potom opravu. Nález, ktorý odmietne, dostane napísaný dôvod. Toto je rovnaké pravidlo ako naša zručnosť s preukázanou recenziou, a to je to, čo zastavuje botov recenzií pred sterom PR podľa objemu.
Udržiavajte PR veľkosť jeho cieľa
Recenzné slučky zväčšujú PR jednu lacnú opravou naraz: strážcov pre hraničný prípad, ktorý nikto nenaráža, test na správanie, ktoré sa nezmenilo, kompatibilný shim. Zručnosť opravuje skutočné chyby v zamýšľanom prípade a zamietava zvyšok písomne. Cenné z nich sa stanú problémami.
Pripravené je kontrolný zoznam
Každá brána CI úlohy zelená na aktuálnej hlave, každý bot recenzií skončil na tejto hlave, nič nečaká na ľudskú, bez nevyriešeného vlákna, bez konfliktu. Keď to drží, agent to nahlási a prestane sledovať.
Po LGTM: pracovný postup GitHub Actions rieši konflikty zlúčenia
Pracovný postup má dve úlohy.
Brána rozhoduje, čo každý PR potrebuje
Brána je lacná: bez agenta, bez checkout PR kódu. Beží na každom push do main, každom skončení CI, každom označení a recenzii, a každých 30 minútach, a jeden GraphQL dotaz mu dáva každý otvorený PR LGTM. Pre každého jeden čisté funkcia rozhoduje, čo urobiť. Pridať RTM, ak je schválený niekým iným ako autorom, zelený a bez konfliktu. Nechať to tak, ak prebieha recenzia. Znova spustiť červenú CI raz. Poslať konflikt, alebo CI, ktorý je stále červený po jeho znova spustení, oprávcovi.
Oprávca agent zlučuje main
Oprávca je úloha agenta pre jeden PR v jednej hlave. Zlúči main do vetvy bez commitu, dá agentovi konfliktné súbory a zlyhávajúce denníky, a nechá ho upravovať iba konfliktné súbory a súbory, ktoré PR už zmení. Potom si položí jednu otázku.
Môže sa tento PR pozemniť bez zmeny riadka, ktorý napísal jeho autor?
Ak áno, verdikt je MODERNIZE. Agent rieši konflikt okolo línií autora, validátor kontroluje výsledok, a pracovný postup vytlačí normálny merge commit. Ak nie, pretože main zmazal funkciu, ktorú PR upravuje, alebo PR vlastný kód zlyhá CI, verdikt je REWORK. Nič sa nevytlačí, LGTM sa sníži a autor dostane komentár s najmenším prepisom. Ak main už robí, čo PR robí, verdikt je CLOSE a osoba ho zavrie.
Validátor uchovávajúci každý riadok, ktorý napísal autor
Validátor je to, čo robí pravidlo držať. Odmietne akúkoľvek zlúčenie, ktoré zahodí riadok, ktorý PR pridal, alebo riadok, ktorý main pridal do konfliktného súboru. Odmietne úpravy mimo povolené súbory, zvyšné značky konfliktov a zmeny CI alebo bezpečnostných súborov. Agent, ktorý sa pokúša „opraviť" kód autora, skončí s označením žiadajúcim osoba, nikdy s push. Pracovný postup vytlačí bez sily, a len ak sa vetva nespustila od začiatku pokusu. Jeden pokus na hlavu a základňu, dva na hlavu, tri komentáre na PR za deň.
Nikdy sa nezlučuje
RTM, „pripravené na zlúčenie", je vyhlásenie brány, že PR má všetko, čo potrebuje: autorský LGTM, schválenie od niekoho iného, zelená CI a bez konfliktu. Osoba robí zlúčenie. To udržalo návrh malý, a to udržalo argument o tom, či by mal bot zlučovať zo recenzie.
Čo sa zmení pre autora, recenzenta a toho, kto zlučuje
Autor povie raz hotov. Nevrátia sa o tri dni neskôr, aby zlúčili main a čakali na CI znova, a PR agenta sa nerozloží, pretože relácia, ktorá ju otvorila, skončila.
Recenzent otvorí PR, ktorý je zelený a zlučiteľný na dnešnom main, takže ich schválenie je posledný krok a nie začiatok ďalšieho kola.
Ktokoľvek zlučuje pracuje z jedného zoznamu. RTM zostáva, keď brána pridá, a ak main PR zlomí po tom, pracovný postup to opraví a značka ostáva.
A autor udržiava kontrolu svojho kódu. Najhoršie, čo môže bot urobiť s vetvou, je pridať merge commit, ktorý validátor skontroloval líniu po línii.
Prečo náš starý resolver konfliktu zlúčenia nikdy nespustil
Mal sme resolver konfliktu pred tým. Detektor našiel konfliktné PR a komentoval na nich, a resolver spustil, keď niekto pridal značku, ktorá ho prosí. V rovnakom období detektor bežal asi 2 500-krát. Resolver spustil nula krát.
Nemyslím si, že by bol niekto lenivý. Vývojár, ktorý považuje PR za hotový, sa nevracia k tomu, aby stlačil tlačidlo. Automatizácia, ktorá čaká na to, aby si požiadali, si nepožiada. To je dôvod, prečo sa ten začína od LGTM, momentu, keď autor povie, že je hotový, a robí zvyšok bez nich.
Čo zatiaľ nefunguje?
Dve veci, a radšej ich tu poviem, ako by ste ich našli.
Pracovný postup je v suchom spustení
Jeho brána iba zaznamenáva, čo by robila, kým to premenná úložiska nepovedala. Pred tým, ako sa to dostalo tak ďaleko, recenzia, ktorá iba udržuje nálezy, ktoré môže preukázať zlyhávajúcim testom, našla v nej jedenásť chýb. Niektoré sú hodnoverhodné, ak postavíte svoje vlastné. Vyhľadávanie značiek GitHub oneskoruje, takže PR, ktoré vrátené, mohla stratiť značku pred pár sekundami, a rozhodnutie musí skontrolovať aktívne značky. Marker „táto hlava už mala svoju opätovnú reálnu zlyhanú API vyzýva spôsobiť, že hlava použije jej jediný pokus o opakované pokusovanie. A kontrola „stratite nie riadok", ktorá nenasleduje premenovania, vidí všetok riadok preferencujúceho súboru ako stratený.
Spúšťače agenta boli dole
Od 19. októbra každá úloha zameraná na naše spúšťače agenta zlyhala, aby dostala stroj: 406 zrušených, 24 stále čakal, keď som skontroloval. Brána beží inde a je v poriadku, ale oprávca potrebuje spúšťač agenta, a mŕtvy vyzerá presne ako tichý deň. Nič zlyhalo nahlas. Úlohy boli zaradené do frontu a potom zrušené. Ak si to postavíte, upozornite na spustenia oprávcu, ktoré sú vo fronte.
Takže čísla vyššie sú obrázok pred. Práve teraz máme 27 otvorených PR LGTM, 7 z nich s červenými CI a žiadne s RTM. To sú čísla, ktoré by sa to malo zmeniť, a ja budem hlásať, čo to urobilo.
Ako nainštalovať zručnosť babysit-pr
github.com/LivinTribunal/babysit-pr-skill má:
SKILL.md, zručnosť, s krátkou sekcií „nakonfigurujte raz" pre vaše pracovné postupy CI, review boty a kontroly procesu.scripts/pr-wait, sledovateľ. Potrebuje Python a autentifikovanýgh.docs/after-lgtm.md, návrh po-LGTMpracovného postupu: značky, brána, oprávca, pravidlo, že nikdy nezmení líniy autora, a jedenásť chýb.
Pracovný postup je návrh namiesto súboru na kopírovanie, pretože ten nás beží proti označovaniu jednej spoločnosti, spúšťačom a CI. Postavte si svoju z dokumentácie, pošlite ju v režime len-záznamu, čítajte deň jej rozhodnutí, potom ju zapnite.
Spája sa s architektúrnym vzorom , ktorý rozhoduje, kto píše kód, a zrnkom , ktorý rozhoduje, ako vyzerá kód. babysit-pr je to, čo sa stane potom, čo ktorýkoľvek z nich otvorí pull request. Ak vylaďujete samotného agenta, test A/B CLAUDE.md a limit kontextu, ktorý znížil použitie tokenu o 17% pokrývajú pokyny a náklady.
