Temel Çıkarımlar
- Kod yazmak artık yavaş kısım değil. 31 günde ana depomuz 473 pull request birleştirdi. Bunların 130’u birinin geri dönüp ana dalı dalın içine birleştirmesi gerekiyordu, toplam 239 birleştirme işlemesi ve bunların 238’i bir kişi tarafından yapıldı.
- Bunun gerekli olduğu PR’lar açılmadan birleştirilmeye kadar orta değer olarak 44 saatini aldı. Gerekmeyen olanlar 2 saatini aldı. Üç günden daha uzun açık kalan 60 PR’ın 51’i en az bir kez ana dalın birleştirilmesini gerekti.
- babysit-pr işi bir etiketle böler:
LGTM, “bana uygun görünüyor” anlamına gelir, yazar işi tamamladığında ekler. Bundan öncesi, bir beceri ajanı PR’da kalır CI yeşil ve her inceleme botu yanıtlanana kadar. Bundan sonrası, bir GitHub Actions iş akışı PR’ı bir kişi birleştirene kadar birleştirilebilir tutar ve yazardan başka biri onayladığındaRTM, “birleştirmeye hazır” ekler. - İş akışı asla birleştirmez, asla kapatmaz ve yazarın yazdığı bir satırı değiştirmez. Yazarın kodunun etrafında çözemediği bir çatışma yazara
REWORKolarak geri döner. - Beceri kamuya açık, MIT lisanslı: GitHub’da babysit-pr-skill , gözlemci betiği ve iş akışının tasarımı ile. İş akışı kendisi hala depo üzerinde kuru koşumda ve bunun nedenini aşağıda söylerim.
Tamamlanan pull requestler neden eski hale gelir?
Kod yazmak yavaş kısım olmaktan çıktı. Mimar deseni ve ajanlar yazma işleminin çoğunu yaparak, depomuz günde yaklaşık 13 işlem alır ana dalında. Bu gönderme için iyidir ve açık her pull request için kötüdür, çünkü bu işlemlerin her biri bir PR’ı çatışmaya sokabilir veya CI’sini kızıllaştırabilir.
Son 31 günün birleştirilen PR’larını çektim zamanın nereye gittiğini görmek için.
44’e karşı 2, bir neden değil, bir korelasyondur. Daha uzun açık kalan bir PR ana dalının onun altında hareket etmesi için daha fazla zaman verir, bu nedenle birleştirme gerekme ihtimali daha fazladır. Ama birleştirmeler kendileri 239 kez bir ay içinde birisi tarafından yapılan gerçek işlemlerdir. Beş kişi bunların 238’ini elle yaptı. Bir PR açık olduğu yedi gün içinde ana dalın sekiz birleştirilmesini gerekti.
Onay kendisi hızlı idi. Bir PR ilk onayını aldıktan sonra, birleştirilmeye kadar olan orta değer sıfır saatiydi. Bekleme bundan öncesi oldu: yazar bitti, ardından PR bir inceleyici ona varana kadar oturdu ve oturduğu sürece ana dal hareket etti. 20 Ekim’de tamamlanan PR’ları LGTM ile etiketlemeye başladık. O zamandan beri birleştirilen 20 ortası LGTM ile birleştirme arasında 38 saatini bekledi ve dörtte bir 78’den fazla beklemedi.
Bu açığı kapatmak içindir. Kimse burada dikkatsiz değil. Yazar yapıldığını düşünür, inceleyici henüz açmadı ve dal ikisinin arasında çürür.
İşinizi büyütmeye hazır mısınız?
Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.
Neden GitHub’ın actions/stale ile eski pull requestleri kapatmayasınız?
Eski pull requestlere karşı alışık cevap actions/stale : bir dizi gün hareketsizlikten sonra sorunlara ve pull requestlere eski bir etiketi ekleyen ve en sonra birine kadar otomatik olarak kapatması ya yazı yazar ya da iter, GitHub Eylemi.
Bu, kimsenin üzerinde çalışmadığı pull request için uygun. Bizim olduklarında hiçbir şey yapmaz. Bizimkiler ana dal onların altında hareket ederken bir inceleyici bekleme sırasında eski hale gelen tamamlanmış çalışmaydı. Bunları kapatmak işi atar ve eski bir etiket yazara zaten bildiklerini söyler. PR’ın ihtiyacı olan birisi ana dalı içine birleştirmek, kırmızı CI işini yeniden çalıştırmak ve bir kişi onaylayana kadar yeşil tutmaktır. Bu nedenle eski pull requestleri kapatmak yerine, bunları birleştirilebilir tutuyor.
babysit-pr pull requestleri birleştirilebilir nasıl tutar
Bölüm kimin beklediğini takip eder. LGTM öncesi yazar hala PR’da, genellikle ajanın oturumu ve beceri bu oturumu işi başarıyla tamamladığını beyan etmek yerine útil işler yapması için tutar. LGTM sonrası yazar ilerledi, bu nedenle işler birinin bakmasına gerek duymayan şeye gider: iş akışı iş akışı kimsenin bakıp bakmamasına bakılmaksızın çalışır.
LGTM “bana uygun görünüyor” anlamına gelir. Çoğu ekipler üzerinde bir inceleyici başkasının kodu hakkında söyler. Burada yazar kendi PR’larına bir etiket olarak koyar bu da “ben bitirdim, benim için yapacak bir şey yok” anlamına gelir. Bu bir insanın söylediğidir: ajan yalnızca PR’ı başkasına devredilmesi söylendiğinde ekler. Bu etiket sonrası her şey için seçim yapan ve bir geliştiriciyi rahat bırakan şey budur bir bota dallarına itme izni verirken.
Bültenimize katılın
En son ipuçlarını, trendleri ve teklifleri ücretsiz alın.
LGTM Öncesi: Bir Claude Code Becerisi PR’ı Hazır Duruma Taşır
Beceri Theo Browne’ın tstack
içinde babysit-pr becerisi olarak başladı. Onun gözlemcisini ve temel kurallarını tutdum ve nerede durduğunu değiştirdim.
Pull Request Başına Bir Gözlemci
pr-wait bir pull request’ı yoklar ve gerçek olaya başına bir satır yazdırır: bir kontrol başarısız, tüm kontroller tamamlandı, birisi yorum yaptı ya da gözden geçirdi, ana dal bu PR’ın dokunduğu dosyaların altında hareket etti, dal geride kaldı ya da çatışma içinde, PR birleşti. Claude Code’da Monitor aracı altında çalışır, bu nedenle her satır ajanı bir kez uyandırır. İşlem gerektirmeyen olay mesaj olmadan dönüşü sona erdirir. “Hala bekleme” haber değildir ve “bunu elli kez söyleyen” bir ajan bağlamını kendisinin hiçbir şeyle doldurur.
Kodu Dokunmadan Öncesi Kırmızı CI İşini Sırala
Kırmızının dört türü var ve yalnızca biri bir kod onarısıdır:
- PR bunu kırdı. En küçük değişiklikle düzelt.
- Çalıştırıcı arızalandı. Başarısız işleri bir kez yeniden çalıştır. Aynı baş üzerinde ikinci başarısızlık bir arıza değil.
- Ana dal kırmızı. Birinin özellik dalı üzerinde ana dalı düzeltme. Bildir ve bekle.
- Bir işlem kontrolü kırmızı, örneğin PR onaylı bir sorunu bağlamaz. Bu bir kişinin adımıdır.
Yapılandırılmadan kalan ajanlar tümünü birinci olarak değerlendirir ve PR bir test için geçici çözüm büyümesi.
Bir Bulmayı Düzeltmeden Öncesi Kanıtla
İnceleme bulması ajanı kabul eder başarısız bir test önce, ardından onarı. Bulmayı reddeden yazılı neden alır. Bu bizim kanıtlanmış inceleme becerisinin aynı kuralı ve bu inceleme botlardan hacım tarafından bir PR’ı yönlendirmekten durduran şey.
PR’ı Hedefinin Boyutunda Tut
Değerlendirme döngüleri bir PR’yı ucuza gördüğü şeyde bir büyütür: kenar durumu hiç kimse vurmaz için bir koruma, davranış değişmedi için bir test, bir uyumluluk parçası. Beceri amaçlanan durumda gerçek böcekleri düzeltir ve geri kalanını yazılı olarak reddeder. Değer olanlar sorun haline gelir.
Hazır bir Kontrol Listesidir
Her gating CI işi yeşil mevcut başta, her inceleme botu bu başta bitmiş, hiçbir şey bir insana bekleme, çözümlenmemiş iş parçacığı, çatışma yok. Bunu tuttuğunda ajan bildir ve izleme durdurur.
LGTM Sonrası: Bir GitHub Actions İş Akışı Birleştirme Çatışmalarını Çözer
İş akışının iki işi var.
Kapı Her PR’ın İhtiyacına Karar Verir
Kapı ucuz: ajan yok, PR kodu kontrolü yok. Ana dalına her itme, her CI’yi tamamlama, her etiket ve gözden geçirme ve her 30 dakika çalıştırır ve bir GraphQL sorgusu ona her açık LGTM PR verir. Her biri için saf bir işlev ne yapılacağına karar verir. RTM ekle eğer yazardan başkası tarafından onaylandı, yeşil ve çatışmasız. Bir inceleme çalıştırılıyorsa yalnız bırak. Kırmızı CI’yi bir kez yeniden çalıştır. Bir çatışma veya yeniden çalıştırıldıktan sonra hala kırmızı CI onarıcısına gönder.
Onarıcı Ajan Ana Dalı Birleştirir
Onarıcı bir ajanın bir PR’a bir başta işi. Bir çatışmaya ana dali dal içine işleme olmadan birleştirir, ajanı çatışan dosyalar ve başarısız günlükleri verir ve yalnızca çatışan dosyalar ve PR zaten değişiklikleri yapan dosyaları düzenlemesine izin verir. Ardından bir soru sorar.
Bu PR yazarın yazdığı satırı değiştirmeden inebilir mi?
Eğer evet, karar MODERNIZE. Ajan yazarın satırlarının etrafındaki çatışmayı çözer, bir doğrulayıcı sonucu kontrol eder ve iş akışı normal bir birleştirme işlemesi iter. Eğer hayır, çünkü ana dal PR’ın düzenlediği işlevi sildi ya da PR’ın kendi kodu CI başarısız, karar REWORK. Hiçbir şey itilmez, LGTM açılır ve yazar en küçük yeniden yazma işlemiyle bir yorum alır. Eğer ana dal zaten PR yapıyor, karar CLOSE ve bir kişi kapatır.
Doğrulayıcı Yazarın Yazdığı Her Satırı Tutar
Doğrulayıcı kuralın tuttuğunu yapanıdır. PR ekledi satırı ya da ana dal çatışan dosyaya ekledi satırı bırakan herhangi bir birleştirmeyi reddeder. İzin verilen dosyaların dışında düzenlemeler, kalan çatışma işaretleyicileri ve CI’ya ya da güvenlik dosyalarına değişiklikleri reddeder. Yazarın kodunu “düzeltmeye” çalışan ajan bir itme ile değil, insan sorma etiketiyle sona erer. İş akışı zorla olmadan iter ve yalnızca başla itme başladığından beri dal hareket etmediyse. Bir deneme başına başta ve iki başına başta, üç PR başına gün yorumları.
Asla Birleştirmez
RTM, “birleştirmeye hazır” kapının tarafından bir PR kapısı ifadesidir bir PR tüm ihtiyacına sahip: yazarın LGTM, başkası tarafından onay, yeşil CI ve çatışma yok. Bir kişi birleştir. Bu tasarımı küçük tuttu ve bir bota birleştirmeye karar argümanını iş akışı dışında tuttu.
Yazar, İnceleyici ve Kim Birleştirir İçin Neler Değişir
Yazar bir kez tamamlandığını söyler. Üç gün sonra ana dalı birleştirmek ve CI beklemek için geri gelmez ve ajanın PR oturumunu açtığı oturumun sona ermesi nedeniyle çürür.
İnceleyici bu ana dalın güncellemesinde yeşil ve birleştirilebilir bir PR açar, böylece onay son adım ve başka bir dönüş değil.
Kim birleştirir bir listeden çalışır. RTM kapı ekledikten sonra kalır ve eğer ana dal PR’ı sonra kırar iş akışı düzeltir ve etiket kalır.
Ve yazar kodunun kontrolünü tutar. Bot yapabileceği en kötü şey bir birleştirme işlemesi eklemektir doğrulayıcı satır satır kontrol etti.
Neden Eski Birleştirme Çatışma Çözümleyicimiz Hiç Çalışmadı
Bu çatışma çözümleyicisinden öncesi bir vardı. Bir dedektif çatışan PR’ları buldu ve yorum yaptı ve çözümleyici birisi yorum yaptı etiketini eklediğinde çalıştı istemek. Aynı dönemde dedektif çalıştırıldı 2.500 kez hakkında. Çözümleyici çalıştırıldı sıfır kez.
Biri tembel olduğunu düşünmüyorum. PR’ı tamamlanan bir geliştirici bir düğmeyi basmak için geri gelmez. Sorulmasını beklemek otomasyonun sorulmayacak. Bu nedenle bu LGTM başlıyor, yazar tamamlandığını söylerken, geri kalanında onlar yapmadan.
Henüz Ne Çalışmıyor?
İki şey ve onları bulmaktan ziyade onları söylemeyi tercih ederim.
İş Akışı Kuru Koşumda
Onun kapısı bir depo değişkeni aksi söylemedikçe ne yapacağını yalnızca günlüğe kaydeder. Buna gitmeden öncesi, yalnızca başarısız test kanıtla bulguların tutabileceğini inceleme 11 hata buldu. Birkaçı değer kendi inşa ederseniz. GitHub’ın etiket araması geri kalır, bu nedenle döndürür bir PR saniye önce etiketini kaybetmiş ve karar canlı etiketleri kontrol etmelidir. Bir “bu başta zaten yeniden çalıştırıldı” başta işaretleyici yeniden çalıştırma çağrısından başlayan bir başarısız API çağrı başta’nın sadece yeniden denemesi kullan. Ve “satırı kaybetme” kontrolü isimleri takip etmez dosya adlı satırın her satırı kayıp olarak görür.
Ajan Çalıştırıcılar Aşağı Idi
Ekim 19’ından beri makine almak için amaçlanan her iş başarısız oldu ajanın çalıştırıcılarımız: 406 iptal edildi, 24 hala kuyruk kontrol ederken. Kapı başka yerde çalıştırır ve iyi, ama onarıcı ajanın çalıştırıcısını gerektirir ve ölü bir sessiz bir güne tam görünür. Hiçbir şey yüksek başarısız. İş sıraya aldı ve sonra iptal edildi. Bunu inşa ederseniz, kuyruk onarıcı çalıştırıldı uyarı.
Bu nedenle sayılar öncesi resimdir. Şimdi 27 açık LGTM PR, 7 kırmızı CI ile ve hiç bir RTM ile. Bu sayılar bunun değiştirmesi ve ne yaptığını bildir.
babysit-pr Becerisini Nasıl Yükleyeceksiniz
github.com/LivinTribunal/babysit-pr-skill var:
SKILL.md, beceri, CI iş akışlarınız, inceleme botlarınız ve işlem kontrolleriniz için kısa “bir kez yapılandırma” bölümü ile.scripts/pr-wait, gözlemci. Python ve doğrulanmışghgerektirir.docs/after-lgtm.md, iş akışının tasarımı: etiketler, kapı, onarıcı, yazarın satırlarını değiştirmediği kural ve 11 hata.
İş akışı kopyalamak için bir dosya yerine bir tasarımdır çünkü bizimki bir şirketin etiketlerine, çalıştırıcılarına ve CI’ye karşı çalıştırır. Dokümandan yapılandır, günlük sadece modunda gönder, bir günü kararlarını oku, ardından açtığı.
Bununla eşleştirir mimar deseni , kod yazanı belirler ve tane , kod neye benzer belirler. babysit-pr her iki açılmış pull requestten sonra olur. Ajanın kendisini ayarladığınızsa, CLAUDE.md A/B testi ve token kullanımı 17% azaltan bağlam sınırı talimatları ve maliyeti kapsar.
