Những điều rút ra chính
- Viết mã không phải là phần chậm nữa. Trong 31 ngày repo chính của chúng tôi đã merge 473 pull request. 130 trong số chúng cần ai đó quay lại và merge main vào nhánh, 239 merge commit tổng cộng, và 238 trong số đó được thực hiện bởi một người.
- Các PR cần điều đó đã mất trung vị 44 giờ từ mở đến merge. Những cái không cần chỉ mất 2 giờ. Trong số 60 PR vẫn mở lâu hơn ba ngày, 51 cần ít nhất một merge của main.
- babysit-pr chia công việc tại một nhãn:
LGTM, “looks good to me”, mà tác giả thêm khi công việc hoàn thành. Trước đó, một skill giữ agent trên PR cho đến khi CI xanh và mọi review bot được trả lời. Sau đó, một GitHub Actions workflow giữ PR có thể merge được cho đến khi một người merge nó, và thêmRTM, “ready to merge”, một khi ai đó khác ngoài tác giả phê duyệt. - Workflow không bao giờ merge, không bao giờ đóng, và không bao giờ thay đổi một dòng tác giả đã viết. Một xung đột nó không thể giải quyết xung quanh mã của tác giả sẽ quay lại tác giả như
REWORK. - Skill là công khai, được cấp phép MIT: babysit-pr-skill trên GitHub , với watcher script và thiết kế của workflow. Chính workflow vẫn còn trong dry run trên repo của chúng tôi, và tôi nói dưới đây tại sao.
Tại sao các pull request hoàn thành lại trở nên trễ hạn?
Viết mã không còn là phần chậm. Với mẫu architect và agent làm hầu hết việc gõ, repo của chúng tôi nhận khoảng 13 commit một ngày vào main. Điều đó tốt cho việc ship nhưng tồi tệ cho mỗi pull request mở, vì mỗi một trong những commit đó có thể đặt PR vào xung đột hoặc biến CI của nó thành đỏ.
Tôi đã rút lại 31 ngày của các merged PR để xem thời gian đã đi đâu.
Con số 44 so với 2 là một tương quan, không phải một nguyên nhân. Một PR vẫn mở lâu hơn cho main nhiều thời gian hơn để di chuyển dưới nó, vì vậy nó có nhiều khả năng cần một merge. Nhưng các merge chính nó là công việc thực sự mà ai đó đã làm 239 lần trong một tháng. Năm người thực hiện 238 trong số chúng bằng tay. Một PR cần tám merge của main trong bảy ngày nó vẫn mở.
Chính sự phê duyệt đã nhanh chóng. Một khi PR nhận được sự phê duyệt đầu tiên, thời gian trung vị để merge là không. Chờ đợi xảy ra trước đó: tác giả hoàn thành, sau đó PR ngồi cho đến khi một reviewer có thời gian xem nó, và khi nó ngồi, main di chuyển. Chúng tôi bắt đầu gắn nhãn các PR hoàn thành LGTM vào ngày 20 tháng 10. 20 cái merge kể từ đó đã chờ trung vị 38 giờ giữa LGTM và merge, và một trong bốn cái chờ hơn 78 giờ.
Đây là khoảng trống cho cái này. Không ai bất chấp ở đây. Tác giả nghĩ họ đã hoàn thành, reviewer chưa mở nó, và nhánh thối rữa trong khoảng thời gian đó.
Sẵn sàng phát triển doanh nghiệp của bạn?
Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.
Tại sao không đóng các pull request trễ hạn với actions/stale?
Câu trả lời thường lệ cho các pull request trễ hạn là actions/stale : một GitHub Action thêm nhãn stale vào issues và pull request sau một số ngày không hoạt động, và tự động đóng chúng một vài ngày sau trừ khi ai đó bình luận hoặc push.
Điều đó phù hợp với một pull request mà không ai đang làm việc. Nó không làm gì cho những cái chúng tôi có. Của chúng tôi là công việc hoàn thành trở nên trễ hạn khi chúng đợi một reviewer, vì main di chuyển dưới chúng. Đóng chúng vứt bỏ công việc, và nhãn stale cho tác giả biết điều họ đã biết. Điều PR cần là ai đó để merge main vào, chạy lại CI job đỏ và giữ nó xanh cho đến khi một người phê duyệt nó. Vì vậy thay vì đóng các pull request trễ hạn, chúng tôi giữ chúng có thể merge được.
Cách babysit-pr giữ các pull request có thể merge được
Sự chia cắt theo dõi ai đang chờ. Trước LGTM tác giả vẫn còn trên PR, thường là một phiên agent, và skill giữ phiên đó làm công việc hữu ích thay vì tuyên bố chiến thắng khi mã biên dịch được. Sau LGTM tác giả đã chuyển đi, vì vậy công việc đi đến một cái không cần họ: một workflow chạy cho dù ai có đang nhìn hay không.
LGTM viết tắt cho „looks good to me". Trên hầu hết các nhóm một reviewer nói nó về mã của người khác. Ở đây tác giả đặt nó trên PR của riêng họ như một nhãn có nghĩa là „tôi đã xong, không còn gì để tôi làm". Đó là lời nói của một người: agent chỉ thêm nó khi nó được yêu cầu giao PR. Nhãn đó là sự chọn tham gia cho mọi thứ sau nó, và đó là điều làm cho một developer thoải mái khi cho phép một bot push vào nhánh của họ.
Tham gia bản tin của chúng tôi
Nhận các mẹo, xu hướng và ưu đãi mới nhất miễn phí.
Trước LGTM: một Claude Code skill mang PR đến sẵn sàng
Skill bắt đầu như babysit-pr skill trong tstack của Theo Browne. Tôi đã giữ lại watcher của nó và các quy tắc cốt lõi của nó và thay đổi nơi nó dừng.
Một watcher cho mỗi pull request
pr-wait poll một pull request và in một dòng cho mỗi sự kiện thực sự: một check failed, tất cả checks finished, ai đó bình luận hoặc review, main di chuyển dưới các tệp PR này chạm, nhánh đi sau hoặc vào xung đột, PR merged. Trong Claude Code nó chạy theo Monitor tool, vì vậy mỗi dòng đánh thức agent một lần. Một sự kiện không cần hành động kết thúc turn mà không có thông điệp. „Still waiting" không phải là tin tức, và một agent nói nó năm mươi lần lấp đầy context của chính nó với không có gì.
Sắp xếp CI job đỏ trước khi chạm mã
Có bốn loại đỏ, và chỉ có một là một code fix:
- PR đã phá vỡ nó. Sửa nó với thay đổi nhỏ nhất.
- Runner flaked. Chạy lại các failed jobs một lần. Một thất bại thứ hai trên cùng head không phải là một flake.
- Main đỏ. Không sửa main trên nhánh feature của ai đó. Báo cáo nó và chờ đợi.
- Một process check đỏ, ví dụ PR không liên kết một issue được phê duyệt. Đó là một bước cho một người.
Các agent bị bỏ một mình coi tất cả bốn như cái đầu tiên, và PR phát triển một workaround cho một test bị hỏng trên main.
Chứng minh một review finding trước khi sửa nó
Một review finding mà agent chấp nhận trước tiên nhận một failing test, rồi fix. Một finding nó bác bỏ nhận một lý do bằng văn bản. Đây là cùng quy tắc như skill review proven của chúng tôi, và đó là điều dừng các review bot khỏi điều hướng PR bằng khối lượng.
Giữ PR kích thước của mục tiêu của nó
Các review loop phát triển PR một cheap-looking fix tại một thời gian: một guard cho một edge case mà không ai hit, một test cho behaviour mà không thay đổi, một compatibility shim. Skill sửa các bug thực sự trong trường hợp dự định và từ chối phần còn lại bằng văn bản. Những cái đáng giá trở thành issues.
Sẵn sàng là một danh sách kiểm tra
Mỗi gating CI job xanh trên head hiện tại, mỗi review bot kết thúc trên head này, không có gì chờ đợi trên một người, không có unresolved thread, không có xung đột. Khi điều đó giữ agent báo cáo nó và dừng giám sát.
Sau LGTM: một GitHub Actions workflow giải quyết xung đột merge
Workflow có hai jobs.
Gate quyết định PR nào cần gì
Gate rẻ: không có agent, không có checkout mã PR. Nó chạy trên mỗi push vào main, mỗi CI completion, mỗi nhãn và review, và mỗi 30 phút, và một GraphQL query cho nó mỗi PR LGTM mở. Cho mỗi cái một pure function quyết định phải làm gì. Thêm RTM nếu nó được phê duyệt bởi ai đó khác ngoài tác giả, xanh, và không có xung đột. Để nó một mình nếu một review đang chạy. Chạy lại CI đỏ một lần. Gửi một xung đột, hoặc CI vẫn đỏ sau khi chạy lại của nó, đến fixer.
Fixer agent merge main vào
Fixer là một agent job cho một PR tại một head. Nó merge main vào nhánh mà không commit, cung cấp agent các tệp xung đột và các log thất bại, và cho phép nó chỉnh sửa chỉ các tệp xung đột và các tệp PR đã thay đổi. Sau đó nó hỏi một câu hỏi.
Có thể PR này land mà không thay đổi một dòng tác giả đã viết không?
Nếu có, verdict là MODERNIZE. Agent giải quyết xung đột xung quanh dòng của tác giả, một validator kiểm tra kết quả, và workflow push một normal merge commit. Nếu không, vì main đã xóa function PR chỉnh sửa hoặc mã PR của chính nó fail CI, verdict là REWORK. Không có gì được push, LGTM được loại bỏ, và tác giả nhận được một bình luận với rewrite nhỏ nhất. Nếu main đã làm những gì PR làm, verdict là CLOSE, và một người đóng nó.
Validator giữ mỗi dòng tác giả đã viết
Validator là điều làm cho quy tắc giữ được. Nó từ chối bất kỳ merge nào mà loại bỏ một dòng PR đã thêm, hoặc một dòng main đã thêm vào một tệp xung đột. Nó từ chối các chỉnh sửa bên ngoài các tệp được phép, leftover conflict markers, và thay đổi các tệp CI hoặc security. Một agent cố gắng „sửa" mã của tác giả kết thúc với một nhãn yêu cầu một người, không bao giờ với một push. Workflow push mà không force, và chỉ nếu nhánh không di chuyển kể từ khi nỗ lực bắt đầu. Một nỗ lực cho mỗi head và base, hai cho mỗi head, ba bình luận cho mỗi PR cho mỗi ngày.
Nó không bao giờ merge
RTM, „ready to merge", là tuyên bố của gate rằng một PR có mọi thứ nó cần: LGTM của tác giả, một phê duyệt từ ai đó khác, CI xanh và không có xung đột. Một người làm việc merging. Điều đó giữ thiết kế nhỏ, và nó giữ tranh luận về liệu một bot có nên merge hay không ra khỏi review.
Điều gì thay đổi cho tác giả, reviewer và ai đó để merge
Tác giả nói xong một lần. Họ không quay lại ba ngày sau để merge main và chờ đợi CI lại, và một PR của agent không thối rữa vì phiên làm việc mà mở nó đã kết thúc.
Reviewer mở một PR xanh và có thể merge được trên main hôm nay, vì vậy sự phê duyệt của họ là bước cuối cùng chứ không phải là bước khởi đầu của một vòng khác.
Ai đó để merge làm việc từ một danh sách. RTM vẫn bật một khi gate thêm nó, và nếu main phá vỡ PR sau đó, workflow sửa nó và nhãn vẫn giữ.
Và tác giả giữ lại kiểm soát mã của họ. Điều tồi tệ nhất bot có thể làm cho một nhánh là thêm một merge commit mà validator đã kiểm tra dòng một dòng.
Tại sao merge conflict resolver cũ của chúng tôi không bao giờ chạy
Chúng tôi đã có một conflict resolver trước cái này. Một detector tìm thấy conflicted PRs và bình luận trên chúng, và resolver chạy khi ai đó thêm một nhãn yêu cầu nó. Trong cùng kỳ detector chạy khoảng 2,500 lần. Resolver chạy không lần.
Tôi không nghĩ ai đó là lười biếng. Một developer cho rằng một PR hoàn thành không quay lại nó để nhấn một nút. Automation chờ được yêu cầu sẽ không được yêu cầu. Đó là tại sao cái này bắt đầu từ LGTM, thời điểm tác giả nói họ xong, và làm phần còn lại mà không cần họ.
Điều gì chưa hoạt động?
Hai điều, và tôi sẽ nói chúng ở đây hơn là bạn tìm thấy chúng.
Workflow đang trong dry run
Gate của nó chỉ ghi nhật ký những gì nó sẽ làm cho đến khi một repository variable nói cách khác. Trước nó đi xa như vậy, một review chỉ giữ những phát hiện nó có thể chứng minh với một failing test tìm thấy mười một bug trong nó. Một vài cái đáng biết nếu bạn xây dựng của riêng bạn. GitHub’s label search lag, vì vậy một PR nó trả về có thể đã mất nhãn vài giây trước, và quyết định phải kiểm tra live labels. Một „head này đã có re-run của nó" marker viết trước khi re-run call thành công để một failed API call sử dụng up head’s chỉ retry. Và một „lose no line" check không theo dõi renames thấy mỗi dòng của một tệp được renamed như lost.
Agent runners đã xuống
Kể từ ngày 19 tháng 10 mỗi job hướng đến agent runners của chúng tôi đã thất bại để có một máy: 406 cancelled, 24 vẫn queued khi tôi kiểm tra. Gate chạy ở nơi khác và là tốt, nhưng fixer cần một agent runner, và một dead one trông giống như một ngày yên tĩnh. Không có gì thất bại to nổi. Jobs queued và sau đó được cancelled. Nếu bạn xây dựng cái này, alert trên fixer runs mà ngồi queued.
Vì vậy các số ở trên là bức tranh trước. Phải bây giờ chúng tôi có 27 open LGTM PRs, 7 trong số chúng với CI đỏ và không có với RTM. Đó là những số này sẽ thay đổi, và tôi sẽ báo cáo những gì nó đã làm.
Cách cài đặt babysit-pr skill
github.com/LivinTribunal/babysit-pr-skill có:
SKILL.md, skill, với một phần „configure once" ngắn cho các CI workflows, review bots và process checks của bạn.scripts/pr-wait, watcher. Nó cần Python và mộtghđược xác thực.docs/after-lgtm.md, thiết kế của after-LGTMworkflow: các nhãn, gate, fixer, quy tắc rằng nó không bao giờ thay đổi dòng của tác giả, và mười một bug.
Workflow là một thiết kế hơn là một tệp để sao chép, vì của chúng tôi chạy chống lại một công ty’s labels, runners và CI. Xây dựng của bạn từ doc, ship nó trong chế độ log-only, đọc một ngày của các quyết định của nó, sau đó bật nó.
Nó kết hợp với mẫu architect , quyết định ai viết mã, và grain , quyết định mã trông giống như thế nào. babysit-pr là những gì xảy ra sau khi bất kỳ cái nào mở pull request. Nếu bạn điều chỉnh agent chính nó, CLAUDE.md A/B test và context limit cắt giảm token use 17% bao gồm các instructions và chi phí.
