Cách thực hiện sửa lỗi Issue và PR GitHub dựa trên xác minh với RepoPilot

RepoPilot làm gì

RepoPilot là bộ điều khiển tự lưu trữ dành cho quy trình lặp phần mềm dựa trên xác minh. Công cụ biến các GitHub Issue và pull request trong cùng kho đã chọn thành một quy trình có giới hạn, bao gồm xem xét quy tắc, tạo kiểm thử, tái hiện lỗi, sửa mã, xác minh độc lập và tùy chọn xuất bản nhánh sửa lỗi cùng pull request nháp.

Dự án sử dụng OpenAI Codex SDK để hiểu các quy tắc của kho, thiết kế kiểm thử dựa trên yêu cầu và đề xuất thay đổi mã sản phẩm. Một trình chạy Docker riêng biệt thực thi các kiểm thử trên các ảnh chụp trạng thái kho đã ghim. Bộ điều khiển chỉ công bố kết quả khi bằng chứng được cấu hình và các kiểm tra chính sách đều đạt.

RepoPilot không tự động hợp nhất hoặc triển khai thay đổi. Người bảo trì chọn công việc, xem xét bằng chứng và giữ quyền quyết định hợp nhất cuối cùng.

Giới hạn của quy trình

1. RepoPilot ghim các commit cơ sở và đầu cần thiết.
2. Công cụ tải chính sách đáng tin cậy từ nhánh cơ sở, bao gồm hướng dẫn AGENTS.md áp dụng được.
3. Codex xem xét thay đổi và đề xuất các kiểm thử hoặc ứng viên sửa lỗi.
4. Các kiểm thử được tạo sẽ được cố định trước khi mã sản phẩm được sửa.
5. Một trình chạy riêng biệt thực thi các kiểm thử trên các ảnh chụp trạng thái độc lập.
6. Bộ điều khiển kiểm tra danh tính kiểm thử ổn định, dấu vết lỗi, đường dẫn được bảo vệ, kết quả chính sách và các giới hạn đã cấu hình.
7. Kết quả đủ điều kiện có thể được đặt trên một nhánh riêng và gửi dưới dạng pull request nháp để con người xem xét.

Đối với pull request, RepoPilot so sánh hành vi của cơ sở và đầu. Đối với Issue, trước tiên công cụ yêu cầu đường cơ sở ban đầu đạt, sau đó cố gắng tái hiện lỗi được báo cáo bằng một kiểm thử mới đã cố định trước khi đề xuất sửa lỗi.

Tính năng chính và phạm vi hiện tại

• Đầu vào được ghim: SHA cơ sở và đầu, bản tổng hợp tiêu đề và nội dung, kiểm tra độ mới và khả năng hủy giúp ngăn việc xác minh trên đầu vào lỗi thời.
• Quy tắc kho đáng tin cậy: Chính sách tĩnh hỗ trợ kiểm tra trực tiếp và các quy tắc gọi JavaScript hoặc TypeScript. Các tệp AGENTS.md lồng nhau trên nhánh cơ sở có thể định hướng việc xem xét ngữ nghĩa.
• Thực thi kiểm thử độc lập: Bộ điều khiển ủy quyền việc thực thi cho một trình chạy Docker riêng thay vì tin vào đánh giá của mô hình.
• Nhiều hệ sinh thái kiểm thử: Phiên bản 1.3.0 hỗ trợ trình chạy kiểm thử của Node, Vitest, pytest, kiểm thử Go và bằng chứng JUnit XML tương thích.
• Hỗ trợ monorepo: Cấu hình có thể sử dụng thư mục làm việc, nhiều lệnh kiểm thử có tên và các dịch vụ phụ thuộc dùng một lần.
• Sửa lỗi có giới hạn: Có thể giới hạn số lần thử, số lần thử lại, số lượt gọi mô hình, số token, số lần thực thi tác vụ và tổng thời gian tác vụ.
• Báo cáo có thể truy vết: Báo cáo JSON nguyên tử và bản tóm tắt Markdown rút gọn lưu giữ các phát hiện, kết quả kiểm thử, bản vá, lần thử và trạng thái xuất bản.
• Khôi phục vận hành: Các lệnh tác vụ hỗ trợ kiểm tra, hủy, tiếp tục và chạy lại. Luồng recover xử lý phần còn sót lại do sự cố thuộc quyền sở hữu thông qua xem trước và dọn dẹp đã được xác thực.

Triển khai hiện tại hướng đến các kho công khai, dạng văn bản với tối đa 10.000 tệp hoặc 16 MiB. Công cụ không cung cấp thực thi pull request từ fork, kiểm thử đầu-cuối trên trình duyệt, bảng điều khiển lưu trữ, webhook, hàng đợi phân tán, cài đặt phụ thuộc tự động, hợp nhất tự động hoặc triển khai.

Điều kiện tiên quyết

Bạn có thể tải xuống bản phát hành RepoPilot 1.3.0 portable cho Linux, Windows hoặc macOS nếu không muốn cài Node.js. Để cài đặt từ mã nguồn, hãy chuẩn bị:

• Node.js 22, phiên bản được khuyến nghị
• npm và Git
• Docker được cấu hình để chạy các container Linux
• Khóa API OpenAI khi bật tính năng xem xét, lập kế hoạch kiểm thử hoặc sửa lỗi dựa trên Codex
• Token GitHub khi cần truy cập hoặc xuất bản lên GitHub

Sử dụng các phiên bản 1.3.0 tương ứng cho bộ điều khiển và ảnh Agent. Phải cấp sẵn các ảnh Docker và phụ thuộc dự án vì các container kiểm thử mặc định không có quyền truy cập mạng.

Cài đặt RepoPilot từ mã nguồn

1. Cài đặt, xác thực và xây dựng dự án

Từ kho RepoPilot đã sao chép, hãy cài đặt các phụ thuộc đã khóa, chạy các bước kiểm tra và kiểm thử của dự án, rồi xây dựng bộ điều khiển:

npm ci
npm run check
npm test
npm run build

Các kiểm thử phát triển của RepoPilot sử dụng API, agent, trình chạy giả lập và fixture tổng hợp. Chúng không tiêu tốn hạn mức mô hình, khởi chạy Docker hoặc ghi nội dung lên GitHub.

2. Tạo cấu hình cục bộ

Sao chép cấu hình mẫu được cung cấp:

cp repopilot.example.json config.local.json

Người dùng PowerShell có thể dùng Copy-Item thay cho cp. Chỉnh sửa config.local.json để chỉ định kho đích và một lệnh kiểm thử đáng tin cậy. Giữ cấu hình cục bộ này bên ngoài các ảnh chụp trạng thái kho đang được xem xét.

Cấu hình mẫu tắt tính năng xem xét, sửa lỗi và xuất bản của agent. Chỉ bật riêng từng khả năng sau khi việc xác minh cục bộ đã hoạt động.

3. Xây dựng ảnh Codex Agent

Hãy xây dựng container Agent khi muốn sử dụng tính năng xem xét ngữ nghĩa, lập kế hoạch kiểm thử hoặc sửa lỗi dựa trên Codex:

docker build -f Dockerfile.agent -t repopilot-agent:local .

Đặt OPENAI_API_KEY trong môi trường của bộ điều khiển. Chỉ container Agent nhận khóa này. Thông tin xác thực ChatGPT trên máy tính không được sử dụng lại. Thông tin xác thực GitHub cung cấp qua GITHUB_TOKEN hoặc GH_TOKEN vẫn nằm trong bộ điều khiển.

Chạy kiểm tra pull request cục bộ đầu tiên

Bắt đầu bằng một lần so sánh cục bộ giữa nhánh cơ sở và nhánh tính năng:

npm run dev -- check --config config.local.json --repo /path/to/project --base main --head feature

Thay /path/to/project, main và feature bằng kho lưu trữ cục bộ và các ref tương ứng. Lệnh check cục bộ không xuất bản thay đổi và không chỉnh sửa bản sao mã nguồn.

Cách RepoPilot phân loại các bài kiểm thử được tạo

Các kịch bản được tạo được phân loại là regression hoặc new_behavior. Mặc định là regression.

• Bằng chứng hồi quy: Cùng một trường hợp kiểm thử được thực thi thành công trên bản sửa đổi cơ sở nhưng thất bại trên bản sửa đổi đích.
• Bằng chứng hành vi mới: Trường hợp này thất bại trên bản cơ sở và thành công trên bản đích, đồng thời bài kiểm thử được đề xuất có trích dẫn chính xác yêu cầu từ tiêu đề hoặc nội dung pull request.
• Cần đánh giá: Cả hai bản sửa đổi đều thất bại, một trường hợp bị bỏ qua hoặc bị thiếu, quá trình thực thi thất bại, việc phát hiện kiểm thử thay đổi hoặc kết quả kiểm thử ban đầu thay đổi ngoài dự kiến.

Nhãn do mô hình cung cấp không thể ghi đè bằng chứng từ trình chạy. Hồi quy phải lặp lại với danh tính và dấu vân tay của bài kiểm thử thất bại giống hệt nhau trước khi đủ điều kiện sửa chữa tự động.

Liên tục đánh giá Pull Request

Watcher của RepoPilot thăm dò các pull request không ở trạng thái nháp trong cùng kho lưu trữ và loại trừ các nhánh autofix của chính nó. Chạy một chu kỳ thăm dò khi xác thực cấu hình:

npm run dev -- watch --config config.local.json --once

Sau khi xác nhận kết quả, chạy watcher liên tục:

npm run dev -- watch --config config.local.json

Việc xuất bản là tùy chọn và yêu cầu publish=true. GitHub token phải có quyền ghi Contents và Pull requests của kho lưu trữ. Việc xuất bản tạo các nhánh autofix và pull request ở trạng thái nháp riêng biệt; không bao giờ force-push hoặc tự động hợp nhất.

Trước khi xuất bản, RepoPilot kiểm tra lại các SHA của commit và mô tả pull request. Một nhánh hoặc pull request sửa chữa hiện có chỉ có thể được sử dụng lại khi parent và tree của nó khớp với kết quả đã xác minh.

Tái hiện và sửa một GitHub Issue

Việc sửa Issue phải được maintainer chọn rõ ràng. Để xử lý Issue 123, hãy chạy:

npm run dev -- fix --issue 123 --config config.local.json

Quy trình Issue diễn ra qua ba giai đoạn chính:

1. Thiết lập đường cơ sở: Các bài kiểm thử hiện có phải vượt qua trên bản sửa đổi mục tiêu đã được ghim.
2. Tái hiện lỗi: RepoPilot tạo và đóng băng một bài kiểm thử gắn với mô tả Issue. Bài kiểm thử mới phải tái hiện lỗi được báo cáo.
3. Thử và xác minh bản sửa chữa: Codex đề xuất các thay thế mã, còn trình chạy độc lập kiểm tra bài kiểm thử được tạo và đóng băng, bộ kiểm thử ban đầu và chính sách của kho lưu trữ.

Bằng chứng không đủ, không ổn định hoặc chưa hoàn chỉnh sẽ dừng quy trình để con người đánh giá. RepoPilot không tự động chọn Issue, xác định lộ trình sản phẩm hoặc hợp nhất bản sửa chữa được tạo ra.

Thêm chính sách kho lưu trữ đáng tin cậy

Commit .repopilot/policy.json vào nhánh cơ sở mục tiêu. Ví dụ, quy tắc sau từ chối các bài kiểm thử JavaScript và TypeScript bị vô hiệu hóa:

{
  "rules": [
    {
      "id": "no-disabled-tests",
      "kind": "forbid-call",
      "extensions": [".ts", ".js"],
      "callee": "test.skip",
      "message": "Keep regression tests enabled.",
      "severity": "error"
    }
  ],
  "exceptions": []
}

Các loại quy tắc tĩnh được hỗ trợ gồm forbiddenText, forbid-call và require-call. Quy tắc gọi kiểm tra các lệnh gọi trực tiếp, lệnh gọi có định danh đầy đủ và truy cập thuộc tính bằng chuỗi. Chúng không phân giải bí danh hoặc thực hiện phân tích toàn chương trình. Quy tắc literal cũng có thể khớp với chú thích.

Các ngoại lệ của chính sách có thể xác định ruleId, đường dẫn chính xác, lý do, dấu thời gian hết hạn UTC và bằng chứng chính xác tùy chọn. Ngoại lệ chỉ được tin cậy khi đến từ chính sách cơ sở, và các ngoại lệ đã hết hạn không loại bỏ các phát hiện.

Các quy tắc bắt buộc và cấm chồng lấn sẽ khiến việc đánh giá dừng lại. Pull request sửa đổi các tệp quy tắc đáng tin cậy cần maintainer đánh giá và không thể tự cấp quyền cho các bản sửa chữa của chính mình.

Cấu hình bằng chứng kiểm thử cẩn thận

Reporter mặc định là node và sử dụng node --test. Trước tiên hãy build RepoPilot để reporter đáng tin cậy sẵn sàng sử dụng. Với Vitest, hãy cấu hình reporter=vitest và sử dụng lệnh vitest run rõ ràng trong image đáng tin cậy với các dependency được ghim phiên bản.

• Các cờ của reporter thuộc về controller thay vì lệnh kiểm thử không đáng tin cậy.
• reporter=command chỉ thu thập đầu ra và không thể hỗ trợ xác minh hoặc xuất bản.
• Bỏ qua runner sẽ tạo ra một lần đánh giá chỉ theo chính sách, trong đó các bài kiểm thử được ghi nhận là not_run.
• Không có bài kiểm thử, tất cả bài kiểm thử đều bị bỏ qua, báo cáo sai định dạng và thiếu danh tính bài kiểm thử không bao giờ được tính là thành công.
• Các dịch vụ dependency được cấu hình sử dụng một mạng Docker nội bộ dùng một lần.

Đối với các bài kiểm thử được tạo có liên quan đến những export không tồn tại trên bản cơ sở, hãy kiểm tra các export đó bên trong các trường hợp kiểm thử đang thực thi. Export bị thiếu không nên làm hỏng thao tác import cấp cao nhất trước khi có thể thu thập bằng chứng có cấu trúc.

Quản lý tác vụ đang chạy và đã hoàn tất

RepoPilot lưu trữ các báo cáo và ảnh chụp nhanh trong .repopilot-data. Mỗi tác vụ nhận được bằng chứng JSON và bản tóm tắt Markdown. Các lần thực thi lại sẽ lưu trữ bằng chứng trước đó bằng những tên như TASK.execution-N.json.

Kiểm tra và hủy tác vụ

npm run dev -- tasks list --config config.local.json --status running --limit 20 --offset 0
npm run dev -- tasks show TASK_ID --config config.local.json --format markdown
npm run dev -- tasks cancel TASK_ID --config config.local.json

Việc liệt kê, xem và hủy tác vụ vẫn khả dụng trong khi bộ điều khiển đang giữ khóa ghi. Việc hủy tạo một yêu cầu cố định được kiểm tra trong quá trình xác minh và xuất bản. Yêu cầu này không thể hoàn tác các thay đổi trên GitHub đã hoàn tất.

Tiếp tục hoặc chạy lại công việc

npm run dev -- tasks resume TASK_ID --config config.local.json
npm run dev -- tasks rerun TASK_ID --config config.local.json

resume giữ nguyên danh tính tác vụ, cấu hình và các giới hạn. Tùy theo trạng thái, lệnh này khởi động lại quá trình xác minh hoặc tiếp tục xuất bản đối với tác vụ đã được xác minh. rerun tạo một tác vụ được liên kết bằng các commit đã ghim ban đầu và cấu hình hiện tại, đồng thời giữ lại các báo cáo và đánh dấu hủy trước đó.

Các tác vụ vĩnh viễn, đã kết thúc hoặc đã hết lượt yêu cầu phải được chạy lại. Việc phát lại cũng yêu cầu kho lưu trữ cục bộ hoặc bộ nhớ đệm Git đã được ghi nhận; các đầu vào của pull request được kiểm tra lại trong quá trình phát lại.

Mẹo vận hành nâng cao

Sử dụng các giới hạn thận trọng

Đặt các giá trị có giới hạn cho thời gian chờ tác vụ, maxCalls, maxAttempts, maxTaskExecutions và lượng token sử dụng. Giá trị maxTokens được tính từ mức sử dụng do mỗi lần gọi mô hình báo cáo, nên một lần gọi đơn lẻ có thể vượt quá giá trị này. Không nên coi đây là giới hạn cứng về chi phí.

Tách riêng các lỗi môi trường

RepoPilot phân loại lỗi và áp dụng số lần thử lại giới hạn ở cấp giai đoạn cho các sự cố môi trường đủ điều kiện. Các bài kiểm thử không ổn định, quá trình khám phá thay đổi hoặc bằng chứng chưa đầy đủ sẽ chặn việc sửa chữa tự động thay vì bị coi là lỗi mã đã được xác nhận.

Bảo vệ chuỗi bằng chứng

Các ứng viên sửa chữa phải giữ nguyên danh tính của các bài kiểm thử được tạo, đồng thời truyền base ban đầu, head ban đầu và các trường hợp kiểm thử được tạo theo yêu cầu của quy trình. Các bài kiểm thử, manifest, cấu hình, chính sách và đường dẫn ẩn hiện có được bảo vệ. Các bước kiểm tra chính sách tĩnh và ngữ nghĩa được chạy lại sau khi ứng viên sửa chữa.

Thận trọng khi khôi phục sau sự cố

Phiên bản 1.3.0 bao gồm quy trình recover để xem trước và chủ động dọn dẹp các tài nguyên thuộc về những tác vụ bị gián đoạn. Hãy xác minh rằng tiến trình cũ đã dừng trước khi xóa các khóa cũ. Các khóa và tài nguyên cũ có thể cần được kiểm tra thủ công.

Hiểu ranh giới tin cậy

Bộ điều khiển, báo cáo và trình chạy hoạt động trên máy hoặc worker của bạn, nhưng các lần gọi mô hình Codex sử dụng dịch vụ OpenAI và gửi một phần văn bản kho lưu trữ cùng ngữ cảnh tác vụ đã chọn. Tự lưu trữ RepoPilot không cung cấp khả năng suy luận mô hình ngoại tuyến.

Việc thực thi kiểm thử cung cấp bằng chứng kỹ thuật, không phải chứng thực chống giả mạo trước mã độc. Symlink, submodule, tệp nhị phân và các đường dẫn trùng tên do khác biệt chữ hoa chữ thường sẽ bị từ chối an toàn. Hãy xem hướng dẫn bảo mật của dự án trước khi thực thi các kho lưu trữ không đáng tin cậy.

Kết luận

RepoPilot kết hợp hoạt động xem xét và sửa chữa có Codex hỗ trợ với các đầu vào được ghim, bài kiểm thử cố định, quá trình thực thi Docker độc lập, chính sách kho lưu trữ, số lần thử lại có giới hạn và bằng chứng bền vững. Hãy bắt đầu bằng một lệnh check cục bộ không xuất bản, xác thực cấu hình trình báo cáo và chính sách, sau đó chỉ thêm tính năng theo dõi, sửa Issue và xuất bản pull request nháp khi bằng chứng đáp ứng tiêu chuẩn của nhóm bạn.