Xác thực bản phát hành đầy đủ

Full Release Validation là quy trình tổng hợp cho bản phát hành: điểm vào thủ công duy nhất để xác minh trước khi phát hành. Phần lớn công việc diễn ra trong các quy trình con để có thể chạy lại một môi trường bị lỗi mà không phải khởi động lại toàn bộ quy trình phát hành.

Chạy quy trình này từ một tham chiếu quy trình đáng tin cậy, thường là main, rồi truyền nhánh phát hành, thẻ hoặc SHA commit đầy đủ dưới dạng ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable

provider cũng chấp nhận anthropic hoặc minimax cho quá trình thiết lập ban đầu đa hệ điều hành và lượt chạy agent đầu-cuối. Các tác vụ con có thể tái sử dụng phân giải bộ khung quy trình được gọi từ job.workflow_repository và job.workflow_sha, trong khi đầu vào ref chọn ứng viên cần kiểm thử. Cách này duy trì khả năng sử dụng logic xác thực đáng tin cậy hiện tại khi xác thực một nhánh hoặc thẻ phát hành cũ hơn.

Mỗi quy trình con được kích hoạt phải báo cáo cùng một SHA quy trình như lượt chạy Full Release Validation cha. Nếu main thay đổi giữa lúc kích hoạt quy trình cha và quy trình con, quy trình tổng hợp sẽ đóng an toàn với trạng thái thất bại ngay cả khi bản thân quy trình con thành công. Để xác minh chính xác một commit bất biến, hãy dùng pnpm ci:full-release --sha <target-sha>. Trình trợ giúp tạo một tham chiếu release-ci/* tạm thời được ghim vào origin/main đáng tin cậy hiện tại, chỉ truyền SHA đích làm ref ứng viên, tái sử dụng bằng chứng nghiêm ngặt cho chính xác đích đó khi có sẵn và xóa tham chiếu sau khi xác thực. Truyền -f reuse_evidence=false để buộc chạy mới hoặc --workflow-sha <trusted-main-sha> để chọn một commit quy trình cũ hơn vẫn có thể truy cập từ origin/main hiện tại. Bản thân quy trình không bao giờ tạo hoặc cập nhật các tham chiếu kho lưu trữ.

release_profile=stable và release_profile=full luôn chạy kiểm thử kéo dài trực tiếp/Docker toàn diện. Truyền run_release_soak=true để bao gồm cùng các luồng kiểm thử kéo dài với hồ sơ beta. Việc phát hành ổn định sẽ từ chối một bản kê khai xác thực không có kiểm thử kéo dài này và bằng chứng hiệu năng sản phẩm có tính chặn.

Package Acceptance thường xây dựng tarball ứng viên từ ref đã phân giải, bao gồm các lượt chạy SHA đầy đủ được kích hoạt bằng pnpm ci:full-release. Sau khi phát hành beta, hãy truyền release_package_spec=openclaw@YYYY.M.PATCH-beta.N để tái sử dụng gói npm đã phát hành trong các bước kiểm tra phát hành, Package Acceptance, đa hệ điều hành, Docker theo đường dẫn phát hành và Telegram từ gói. Chỉ dùng package_acceptance_package_spec khi Package Acceptance cần chủ đích xác minh một gói khác. Luồng gói trực tiếp của Plugin Codex tuân theo cùng trạng thái: các giá trị release_package_spec đã phát hành suy ra codex_plugin_spec=npm:@openclaw/codex@<version>; các lượt chạy SHA/cấu phần đóng gói extensions/codex từ tham chiếu đã chọn; và người vận hành có thể đặt trực tiếp codex_plugin_spec cho các nguồn Plugin npm:, npm-pack: hoặc git:. Luồng này cấp quyền phê duyệt cài đặt Codex CLI rõ ràng theo yêu cầu của Plugin đó, sau đó chạy bước kiểm tra sơ bộ Codex CLI và các lượt chạy agent OpenAI trong cùng phiên.

Các giai đoạn cấp cao nhất

Với rerun_group=all, tác vụ Check for reusable validation evidence chạy trước tiên: tác vụ tìm lượt xác thực đầy đủ thành công gần nhất trước đó cho chính xác cùng SHA đích, hồ sơ phát hành, thiết lập kiểm thử kéo dài có hiệu lực và các đầu vào xác thực. Khi có bằng chứng như vậy, mọi luồng đều bị bỏ qua và trình xác minh tổng hợp kiểm tra lại cấu phần cha bất biến, các lượt chạy con và nhật ký kích hoạt. Đây chỉ là cơ chế khôi phục chạy lại cho cùng ứng viên; nó không cho phép tái sử dụng giữa các SHA. Với một ứng viên đã thay đổi, hãy chạy lại mọi cổng gói, cấu phần, cài đặt, Docker hoặc nhà cung cấp bị ảnh hưởng bởi phần chênh lệch đó. Truyền reuse_evidence=false để buộc chạy đầy đủ mới. Việc tái sử dụng bằng chứng chỉ chạy từ main hoặc một tham chiếu release-ci/* chính tắc được ghim bằng SHA mà commit quy trình vẫn nằm trong dòng dõi main đáng tin cậy; các tham chiếu quy trình khác chạy mới các luồng đã chọn.

Cũng với rerun_group=all, tác vụ Verify Docker runtime image assets xây dựng đích Docker runtime-assets với OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Tác vụ chạy song song với các giai đoạn khác và được trình xác minh tổng hợp thực thi bắt buộc; các luồng không còn phải chờ tác vụ này trước khi được kích hoạt. Một rerun_group hẹp hơn sẽ bỏ qua bước kiểm tra sơ bộ này.

Quy trình tổng hợp luôn kích hoạt hiệu năng sản phẩm ở chế độ chỉ tạo cấu phần. OpenClaw Performance chỉ cho phép phát hành báo cáo đối với các lượt chạy theo lịch hoặc một lượt kích hoạt thủ công đặt rõ ràng publish_reports=true. Cơ chế bảo vệ chế độ chỉ tạo cấu phần phải hoàn tất thành công, chứng minh tác vụ phát hành đã tiếp tục bị bỏ qua. Bằng chứng mới và được tái sử dụng ghi lại controls.performanceReportPublication=artifact-only; trình xác minh và bộ chọn tái sử dụng từ chối bằng chứng không có phần xác minh quy trình con hiệu năng đã chuẩn hóa tương ứng.

Trình xác minh tải bản kê khai chính tắc lên với tên full-release-validation-<run-id>-<run-attempt>. Công cụ bằng chứng xác thực ID cấu phần, mã băm, lượt chạy tạo ra và lần thử trước khi tải xuống chính xác ID cấu phần đó. Công cụ giới hạn kích thước ZIP tải xuống, xác minh các byte của tệp dựa trên mã băm sha256: từ REST và truyền phát mục bản kê khai giới hạn duy nhất được cho phép mà không giải nén kho lưu trữ. Một bí danh có tên ổn định tạm thời vẫn được giữ lại cho các trình tiêu thụ phát hành cũ hơn. Trình xác minh luôn ưu tiên cấu phần có kèm định danh lần thử; trong giai đoạn chuyển tiếp, trình chấp nhận tên ổn định chỉ đối với trình tạo bản kê khai v2 ở lần thử 1. Trình từ chối tên cũ đó đối với các lần thử sau và bản kê khai v3.

Với ref=main cùng rerun_group=all, với các tham chiếu release/* và với các tham chiếu alpha Tideclaw, một lượt chạy tổng hợp mới hơn sẽ thay thế một lượt chạy cũ hơn có cùng tham chiếu và nhóm chạy lại. Khi quy trình cha bị hủy, trình giám sát của nó sẽ hủy mọi quy trình con mà nó đã kích hoạt. Các lượt xác thực theo thẻ và SHA được ghim không hủy lẫn nhau.

Các giai đoạn kiểm tra phát hành

OpenClaw Release Checks là quy trình con lớn nhất. Quy trình này phân giải đích một lần và chuẩn bị cấu phần release-package-under-test dùng chung khi các giai đoạn liên quan đến gói hoặc Docker cần đến nó.

Các phần trong luồng phát hành Docker

Giai đoạn luồng phát hành Docker chạy các phần sau khi live_suite_filter trống:

Sử dụng docker_lanes=<lane[,lane]> có mục tiêu trên quy trình trực tiếp/E2E có thể tái sử dụng khi chỉ một luồng Docker thất bại. Các hiện vật phát hành bao gồm các lệnh chạy lại theo từng luồng với đầu vào tái sử dụng hiện vật gói và ảnh khi có sẵn.

Hồ sơ phát hành

release_profile chủ yếu kiểm soát phạm vi live/nhà cung cấp bên trong các bước kiểm tra bản phát hành. Nó không loại bỏ CI đầy đủ thông thường, Bản phát hành trước Plugin, kiểm thử nhanh cài đặt, kiểm thử chấp nhận gói hoặc QA Lab. Các hồ sơ stable và full luôn chạy phạm vi kiểm thử toàn diện E2E kho mã/live và kiểm thử ngâm đường dẫn phát hành Docker. Hồ sơ beta có thể chọn tham gia bằng run_release_soak=true. Kiểm thử chấp nhận gói cung cấp kiểm thử E2E Telegram chuẩn cho gói đối với mọi ứng viên đầy đủ, vì vậy quy trình tổng không chạy trùng trình thăm dò live đó.

Các phần bổ sung chỉ dành cho full

Các bộ kiểm thử này bị stable bỏ qua và được full bao gồm:

stable bao gồm native-live-src-gateway-profiles-anthropic-smoke và native-live-src-gateway-profiles-opencode-go-smoke; thay vào đó, full sử dụng các phân đoạn mô hình Anthropic và OpenCode Go rộng hơn. Các lần chạy lại có trọng tâm vẫn có thể sử dụng các định danh tổng hợp native-live-src-gateway-profiles-anthropic hoặc native-live-src-gateway-profiles-opencode-go.

Chạy lại có trọng tâm

Sử dụng rerun_group để tránh lặp lại các môi trường phát hành không liên quan:

Sử dụng live_suite_filter với rerun_group=live-e2e khi một bộ kiểm thử live thất bại. Các mã bộ lọc hợp lệ được định nghĩa trong quy trình live/E2E có thể tái sử dụng, bao gồm docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker và live-codex-harness-docker.

Định danh live-gateway-advisory-docker là định danh chạy lại tổng hợp cho ba phân đoạn nhà cung cấp của nó, vì vậy nó vẫn phân tách thành tất cả các tác vụ gateway Docker tư vấn.

Sử dụng cross_os_suite_filter với rerun_group=cross-os khi một luồng đa hệ điều hành thất bại. Bộ lọc chấp nhận mã hệ điều hành, mã bộ kiểm thử hoặc cặp hệ điều hành/bộ kiểm thử, ví dụ windows/packaged-upgrade, windows hoặc packaged-fresh. Các bản tóm tắt đa hệ điều hành bao gồm thời gian của từng giai đoạn cho các luồng nâng cấp đóng gói, và các lệnh chạy lâu in ra các dòng Heartbeat để có thể nhận biết một quá trình cập nhật bị treo trước khi tác vụ hết thời gian chờ.

Các lỗi kiểm tra bản phát hành QA chặn quá trình xác thực bản phát hành thông thường. Bước kiểm tra phạm vi công cụ thời gian chạy QA (độ lệch công cụ động giữa openclaw và codex trong cấp tiêu chuẩn) cũng chặn trình xác minh kiểm tra bản phát hành mặc dù luồng tương đương thời gian chạy QA nền tảng chỉ mang tính tư vấn. Các lần chạy Tideclaw alpha vẫn có thể coi các luồng kiểm tra bản phát hành không liên quan đến an toàn gói là tư vấn. Với release_profile=beta, các bộ kiểm thử nhà cung cấp live trong Run repo/live E2E validation mang tính tư vấn: các triển khai mô hình của bên thứ ba thay đổi bên dưới một bản phát hành, vì vậy beta hiển thị lỗi của chúng dưới dạng cảnh báo, trong khi các hồ sơ stable và full vẫn để chúng ở trạng thái chặn. Khi live_suite_filter yêu cầu rõ ràng một luồng live QA có cổng kiểm soát như Discord, WhatsApp hoặc Slack, biến kho mã OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED tương ứng phải được bật; nếu không, quá trình ghi nhận đầu vào sẽ thất bại thay vì âm thầm bỏ qua luồng đó. Chạy lại với rerun_group=qa, qa-parity hoặc qa-live khi bạn cần bằng chứng QA mới.

Bằng chứng cần giữ lại

Giữ bản tóm tắt Full Release Validation làm chỉ mục cấp bản phát hành. Bản tóm tắt này liên kết các mã lần chạy con và bao gồm các bảng tác vụ chậm nhất. Khi có lỗi, trước tiên hãy kiểm tra quy trình con, sau đó chạy lại định danh khớp nhỏ nhất ở trên.

Các hiện vật hữu ích:

• release-package-under-test từ OpenClaw Release Checks
• Các hiện vật đường dẫn phát hành Docker trong .artifacts/docker-tests/
• package-under-test của Kiểm thử chấp nhận gói và các hiện vật kiểm thử chấp nhận Docker
• Các hiện vật kiểm tra bản phát hành đa hệ điều hành cho từng hệ điều hành và bộ kiểm thử
• Các hiện vật tính tương đương QA, tính tương đương thời gian chạy, Matrix và Telegram

Tệp quy trình

• .github/workflows/full-release-validation.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-live-and-e2e-checks-reusable.yml
• .github/workflows/plugin-prerelease.yml
• .github/workflows/install-smoke.yml
• .github/workflows/install-smoke-reusable.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-performance.yml
• .github/workflows/npm-telegram-beta-e2e.yml