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

Full Release Validation là ô phát hành bao trùm. Đây là điểm vào thủ công duy nhất cho bằng chứng tiền phát hành, nhưng phần lớn công việc diễn ra trong các quy trình con để một hộp bị lỗi có thể được chạy lại mà không phải khởi động lại toàn bộ bản phát hành.

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

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

Các quy trình con dùng tham chiếu quy trình đáng tin cậy cho harness và đầu vào ref cho ứng viên đang được kiểm thử. Điều đó giữ cho logic xác thực mới luôn sẵn có khi xác thực một nhánh hoặc thẻ phát hành cũ hơn.

Theo mặc định, release_profile=stable chạy các làn chặn phát hành và bỏ qua quá trình soak live/Docker đầy đủ. Truyền run_release_soak=true để bao gồm các làn soak trong một lần chạy ổn định. release_profile=full luôn bật các làn soak để hồ sơ tư vấn rộng không bao giờ âm thầm mất phạm vi kiểm thử.

Chấp nhận gói thường xây dựng tarball ứng viên từ ref đã phân giải, bao gồm các lần chạy SHA đầy đủ được gửi bằng pnpm ci:full-release. Sau khi phát hành beta, truyền [email protected] để tái sử dụng gói npm đã phát hành trên các kiểm tra phát hành, Chấp nhận gói, đa hệ điều hành, Docker đường dẫn phát hành, và gói Telegram. Chỉ dùng package_acceptance_package_spec khi Chấp nhận gói cần cố ý chứng minh một gói khác.

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

Với ref=main và rerun_group=all, một ô bao trùm mới hơn thay thế một ô cũ hơn. Khi cha bị hủy, bộ giám sát của nó sẽ hủy mọi quy trình con mà nó đã gửi. Các lần chạy xác thực nhánh và thẻ phát hành không hủy lẫn nhau theo mặc định.

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

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

Các chunk Docker release-path

Giai đoạn Docker release-path chạy các chunk này khi live_suite_filter trống:

Dùng docker_lanes=<lane[,lane]> có mục tiêu trên workflow live/E2E tái sử dụng khi chỉ một lane Docker thất bại. Artifact phát hành bao gồm các lệnh chạy lại theo từng lane với artifact gói và đầu vào tái sử dụng image khi có sẵn.

Hồ sơ phát hành

release_profile chủ yếu kiểm soát độ rộng live/provider bên trong kiểm tra phát hành. Nó không loại bỏ CI đầy đủ thông thường, Plugin Prerelease, smoke cài đặt, chấp nhận gói hoặc QA Lab. Với stable, E2E repo/live toàn diện và các chunk Docker release-path là phạm vi soak và chạy khi run_release_soak=true. full buộc bật phạm vi soak và cũng khiến lần chạy bao trùm chạy E2E gói Telegram với artifact gói phát hành cha khi rerun_group=all, để ứng viên pre-publish đầy đủ không âm thầm bỏ qua lane gói Telegram đó.

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; full dùng các shard model Anthropic và OpenCode Go rộng hơn thay thế. Các lần chạy lại tập trung vẫn có thể dùng handle tổng hợp native-live-src-gateway-profiles-anthropic hoặc native-live-src-gateway-profiles-opencode-go.

Chạy lại tập trung

Dùng rerun_group để tránh lặp lại các hộp phát hành không liên quan:

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 id bộ lọc hợp lệ được định nghĩa trong workflow live/E2E 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 shard nhà cung cấp của nó, vì vậy nó vẫn phân nhánh ra tất cả các job Gateway Docker tư vấn.

Dùng cross_os_suite_filter với rerun_group=cross-os khi một làn đa hệ điều hành thất bại. Bộ lọc chấp nhận id hệ điều hành, id 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. Tóm tắt đa hệ điều hành bao gồm thời lượng theo từng pha cho các làn nâng cấp đóng gói, và các lệnh chạy lâu in các dòng Heartbeat để bản cập nhật Windows bị kẹt có thể thấy được trước khi job hết thời gian chờ.

Các làn kiểm tra bản phát hành QA có tính chất tư vấn. Lỗi chỉ thuộc QA được báo cáo dưới dạng cảnh báo và không chặn trình xác minh kiểm tra bản phát hành; chạy lạ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ữ

Giữ bản tóm tắt Xác thực bản phát hành đầy đủ làm chỉ mục cấp bản phát hành. Nó liên kết các id lần chạy con và bao gồm bảng các job chậm nhất. Khi có lỗi, trước tiên hãy kiểm tra workflow con, sau đó chạy lại định danh khớp nhỏ nhất ở trên.

Artifacts hữu ích:

• release-package-under-test từ parent Xác thực bản phát hành đầy đủ và Kiểm tra bản phát hành OpenClaw
• Artifacts đường dẫn phát hành Docker trong .artifacts/docker-tests/
• package-under-test của Chấp nhận gói và artifacts chấp nhận Docker
• Artifacts 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ử
• Artifacts tương đương QA, Matrix và Telegram

Tệp workflow

• .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/openclaw-cross-os-release-checks-reusable.yml
• .github/workflows/package-acceptance.yml