Full Release Validation là lớp bao quát xác thực sản phẩm cho bản phát hành. Phần lớn công việc
diễn ra trong các workflow con để có thể chạy lại một hộp bị lỗi mà không cần khởi động lại
toàn bộ bản phát hành. Chạy bước chuẩn bị bản phát hành trước khi đóng băng Code SHA; bước này
làm mới đầu ra locale của Control UI khi bot nền chưa đưa thay đổi đó vào,
sau đó thực thi cùng phép kiểm tra nghiêm ngặt không fallback mà Pipeline CI phát hành sử dụng.
Đóng băng commit hoàn chỉnh về sản phẩm trước changelog làm Code SHA, sau đó chạy:
provider cũng chấp nhận anthropic hoặc minimax cho quy trình onboarding đa hệ điều hành và
lượt agent đầu-cuối. Trình trợ giúp suy ra cấu hình beta từ các phiên bản gói alpha/beta
và dùng stable trong các trường hợp còn lại. Truyền các đầu vào workflow thay thế bằng
-f key=value; chỉ dùng -f release_profile=full cho đợt rà quét tư vấn diện rộng.
Trình trợ giúp tạo một ref release-ci/* tạm thời được ghim vào một
workflow SHA origin/main đáng tin cậy, chỉ truyền SHA đích dưới dạng ref ứng viên,
và xóa ref tạm thời sau khi xác thực. Mọi workflow con được kích hoạt phải
báo cáo cùng workflow SHA đó. Truyền
-f reuse_evidence=false để buộc chạy mới hoặc
--workflow-sha <trusted-main-sha> để chọn một commit workflow cũ hơn vẫn
có thể truy cập từ origin/main hiện tại. Bản thân workflow không bao giờ tạo hoặc cập nhật
ref của kho lưu trữ.
Khi Code SHA đạt trạng thái xanh, chỉ tạo và commit CHANGELOG.md. Commit mới này
là Release SHA. Chạy cùng trình trợ giúp cho Release SHA. Bằng chứng sản phẩm
chỉ được tái sử dụng khi GitHub chứng minh Release SHA là hậu duệ của
Code SHA và toàn bộ tập hợp đường dẫn đã thay đổi chính xác là CHANGELOG.md; bước kiểm tra trước npm
và kiểm tra chấp nhận gói/cài đặt vẫn chạy trên Release SHA.
release_profile=stable và release_profile=full luôn chạy đợt soak
live/Docker toàn diện. Truyền run_release_soak=true để bao gồm cùng các lane soak
với cấu hình beta. Việc phát hành stable sẽ từ chối manifest xác thực
không có đợt soak 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 full-SHA được kích hoạt bằng pnpm ci:full-release. Sau khi
phát hành beta, 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 bản phát hành, Package Acceptance, đa hệ điều hành,
Docker theo đường dẫn phát hành và Telegram theo gói. Chỉ dùng package_acceptance_package_spec
khi Package Acceptance cần chủ ý chứng minh một gói khác.
Lane gói live của Plugin Codex tuân theo cùng trạng thái: các giá trị
release_package_spec đã phát hành dẫn xuất codex_plugin_spec=npm:@openclaw/codex@<version>;
các lượt chạy SHA/artifact đóng gói extensions/codex từ ref đã 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:. Lane này cấp quyền phê duyệt cài đặt Codex CLI rõ ràng mà
Plugin đó yêu cầu, sau đó chạy bước kiểm tra trước Codex CLI và các lượt agent OpenAI trong cùng phiên.
Lượt cuối cùng không thử lại, với mức suy luận trung bình, gửi tiến trình hiển thị với Codex
final bị lược bỏ, đọc các đầu vào workspace ngẫu nhiên, ghi artifact chính xác của chúng
và gửi thông báo hoàn tất rõ ràng. Việc này phát hiện hồi quy v2026.7.1, trong đó một
lần gửi tiến trình thông thường đã chấm dứt lượt.
Các giai đoạn cấp cao nhất
Đối vớirerun_group=all, job Check for reusable validation evidence chạy
trước tiên. Job này tìm lần xác thực đầy đủ đạt trạng thái xanh gần nhất trước đó có cùng cấu hình bản phát hành,
thiết lập soak hiệu lực và đầu vào xác thực. Các lần chạy lại đúng đích sử dụng
exact-target-full-validation-v1. Một hậu duệ có toàn bộ phần chênh lệch chính xác là
CHANGELOG.md sử dụng changelog-only-release-v1; mọi lane sản phẩm đều bị bỏ qua
và trình xác minh kiểm tra lại độc lập phép so sánh commit của GitHub, artifact cha bất biến,
các lượt chạy con và nhật ký kích hoạt. Bất kỳ thay đổi đích nào khác đều yêu cầu
xác thực Code SHA mới. 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 ref release-ci/*
chuẩn tắc được ghim bằng SHA, có commit workflow vẫn nằm trên dòng dõi main đáng tin cậy;
các ref workflow khác chạy mới các lane đã chọn.
Quá trình xác thực mới hướng tới gói chuẩn bị một tarball bất biến cùng một artifact ảnh Docker
trước khi kích hoạt Plugin Prerelease và OpenClaw Release Checks.
Cả hai workflow con đều xác minh cùng SHA gói, ID artifact, digest dịch vụ,
lần thử của lượt chạy tạo ra và digest kho lưu trữ Docker trước khi sử dụng. Lớp Docker thuần
không phụ thuộc gói sử dụng bộ nhớ đệm GHCR định địa chỉ theo nội dung; các ảnh dành riêng cho ứng viên
vẫn là artifact GitHub bất biến. Các lượt chạy tập trung với đặc tả gói đã phát hành
rõ ràng tiếp tục dùng đường dẫn gói hiện có.
Cũng đối với rerun_group=all, job Verify Docker runtime image assets xây dựng
đích Docker runtime-assets với
OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Job này chạy song song với
các giai đoạn khác và được trình xác minh bao quát thực thi; các lane không còn phải chờ
job này trước khi kích hoạt. rerun_group có phạm vi hẹp hơn sẽ bỏ qua bước kiểm tra trước này.
Workflow bao quát luôn kích hoạt hiệu năng sản phẩm ở chế độ chỉ artifact.
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ần kích hoạt thủ công đặt rõ ràng publish_reports=true. Bộ bảo vệ chỉ artifact
phải hoàn tất thành công, chứng minh job phát hành vẫn 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ó minh chứng workflow con về hiệu năng đã chuẩn hóa tương ứng.
Trình xác minh tải manifest chuẩn tắc lên dưới tên
full-release-validation-<run-id>-<run-attempt>. Công cụ bằng chứng xác thực
ID artifact, digest, lượt chạy tạo ra và lần thử trước khi tải xuống chính xác
ID artifact đó. Công cụ giới hạn kích thước ZIP tải xuống, xác minh byte của nó dựa trên digest
sha256: của REST và truyền trực tuyến mục manifest bị 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 tên ổn định được tạm thời duy trì 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 artifact có định danh lần thử;
trong giai đoạn chuyển tiếp, nó chỉ chấp nhận tên ổn định cho trình tạo manifest v2 ở lần thử 1.
Nó từ chối tên cũ đó đối với các lần thử sau và manifest v3.
Đối với ref=main có rerun_group=all, đối với các ref release/*, và đối với các ref alpha của Tideclaw, một lượt chạy bao quát mới hơn sẽ thay thế lượt chạy cũ hơn có cùng ref và nhóm chạy lại. Khi luồng cha bị hủy, trình giám sát của nó sẽ hủy mọi workflow con mà nó đã điều phối. Các lượt chạy xác thực thẻ và SHA cố định không hủy lẫn nhau.
Các giai đoạn kiểm tra bản phát hành
OpenClaw Release Checks là workflow con lớn nhất. Nó phân giải mục tiêu một lần và xác thực artifact gói dùng chung của lượt chạy bao quát khi có. Một lượt điều phối trực tiếp hoặc tập trung sẽ chuẩn bị artifact release-package-under-test riêng khi các giai đoạn liên quan đến gói hoặc Docker cần đến.
Các phân đoạn đường dẫn phát hành Docker
Giai đoạn đường dẫn phát hành Docker chạy các phân đoạn này khilive_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 lane Docker thất bại. Các artifact phát hành bao gồm lệnh chạy lại theo từng lane
với đầu vào tái sử dụng artifact gói và image khi có sẵn.
Hồ sơ phát hành
release_profile chủ yếu kiểm soát phạm vi trực tiếp/nhà cung cấp trong các bước kiểm tra 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 tra nhanh cài đặt, chấp nhận
gói hoặc QA Lab. Hồ sơ ổn định và đầy đủ luôn chạy phạm vi E2E repo/trực tiếp toàn diện
và kiểm thử kéo dài đường dẫn phát hành Docker. Hồ sơ beta có thể chọn tham gia bằng
run_release_soak=true. Chấp nhận gói cung cấp E2E Telegram gói chuẩn
cho 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ò trực tiếp đó.
Các phần bổ sung chỉ dành cho hồ sơ đầy đủ
Các bộ kiểm thử này bị bỏ qua bởistable và được bao gồm bởi full:
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 shard
mô hình Anthropic và OpenCode Go rộng hơn. Các lần chạy lại có mục tiêu vẫn có thể sử dụng
các handle tổng hợp native-live-src-gateway-profiles-anthropic hoặc
native-live-src-gateway-profiles-opencode-go.
Chạy lại có mục tiêu
Sử dụngrerun_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ử trực tiếp thất bại.
Các id bộ lọc hợp lệ được định nghĩa trong quy trình trực tiếp/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.
Để chạy lại có mục tiêu một phương thức vận chuyển QA, hãy đặt rerun_group=qa-live và sử dụng
bộ chọn chuẩn qa-live-matrix, qa-live-telegram, qa-live-discord,
qa-live-whatsapp hoặc qa-live-slack.
Handle live-gateway-advisory-docker là một handle 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 tán sang tất cả các job Gateway Docker tư vấn.
Sử dụng cross_os_suite_filter với rerun_group=cross-os khi một lane đ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 một 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 theo từng giai đoạn cho các lane nâng cấp gói, và các lệnh chạy lâu
in các dòng Heartbeat để có thể phát hiện bản cập nhật bị treo trước khi job
hết thời gian chờ.
Các lỗi kiểm tra phát hành QA chỉ chặn xác thực bản phát hành thông thường đối với các lane đã chọn
về phạm vi công cụ runtime Matrix, Telegram và QA. Tính tương đương QA, tính tương đương
runtime và các lane trực tiếp Discord, WhatsApp và Slack có cổng kiểm soát mang tính tư vấn và
phát hành artifact trạng thái mà không chặn trình xác minh bản phát hành. Các lần chạy alpha Tideclaw
vẫn có thể coi các lane kiểm tra phát hành không liên quan đến an toàn gói là mang tính tư vấn. Với
release_profile=beta, các bộ kiểm thử nhà cung cấp trực tiếp Run repo/live E2E validation
mang tính tư vấn: các triển khai mô hình 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, còn hồ sơ ổn định và đầy đủ vẫn
coi chúng là lỗi chặn. Khi
live_suite_filter yêu cầu rõ ràng một lane QA trực tiếp có cổng kiểm soát như Discord,
WhatsApp hoặc Slack, biến repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED tương ứng
phải được bật; nếu không, bước thu thập đầu vào sẽ thất bại thay vì âm thầm bỏ qua lane.
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ữ lại
Giữ bản tóm tắtFull Release Validation làm chỉ mục cấp phát hành. Nó liên kết
các id lần chạy con và bao gồm các bảng job chậm nhất. Đối với lỗi, trước tiên hãy kiểm tra
quy trình con, sau đó chạy lại handle phù hợp nhỏ nhất ở trên.
Ghi lại cả Code SHA và Release SHA, chính sách tái sử dụng và tập hợp đường dẫn đã thay đổi,
lần chạy cha Code SHA thành công và lần chạy cha Release SHA gọn nhẹ.
Các artifact hữu ích:
release-package-under-testtừOpenClaw Release Checks- Các artifact đường dẫn phát hành Docker trong
.artifacts/docker-tests/ - Artifact
package-under-testcủa Chấp nhận gói và các artifact chấp nhận Docker - Artifact kiểm tra phát hành đa hệ điều hành cho từng hệ điều hành và bộ kiểm thử
- Artifact tính tương đương QA, tính tương đương runtime và Matrix, Telegram, Discord, WhatsApp hoặc Slack đã chọn
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