Chính sách phát hành

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• stable: các bản phát hành được gắn thẻ, mặc định xuất bản lên npm beta, hoặc lên npm latest khi được yêu cầu rõ ràng
• beta: các thẻ phát hành trước xuất bản lên npm beta
• dev: đầu nhánh đang thay đổi của main

​

Đặt tên phiên bản

• Phiên bản phát hành stable: YYYY.M.D
  • Thẻ Git: vYYYY.M.D
• Phiên bản phát hành sửa lỗi stable: YYYY.M.D-N
  • Thẻ Git: vYYYY.M.D-N
• Phiên bản phát hành trước beta: YYYY.M.D-beta.N
  • Thẻ Git: vYYYY.M.D-beta.N
• Không thêm số 0 ở đầu tháng hoặc ngày
• latest nghĩa là bản phát hành npm stable hiện tại đã được quảng bá
• beta nghĩa là mục tiêu cài đặt beta hiện tại
• Các bản phát hành stable và bản sửa lỗi stable mặc định xuất bản lên npm beta; người vận hành phát hành có thể nhắm mục tiêu latest rõ ràng, hoặc quảng bá một bản dựng beta đã được kiểm định sau đó
• Mỗi bản phát hành OpenClaw stable phát hành gói npm và ứng dụng macOS cùng nhau; các bản phát hành beta thường xác thực và xuất bản đường dẫn npm/gói trước, còn bước dựng/ký/công chứng ứng dụng Mac được dành cho stable trừ khi được yêu cầu rõ ràng

​

Nhịp phát hành

• Các bản phát hành đi theo hướng beta trước
• Stable chỉ theo sau sau khi bản beta mới nhất được xác thực
• Người bảo trì thường cắt bản phát hành từ một nhánh release/YYYY.M.D được tạo từ main hiện tại, để việc xác thực và sửa lỗi phát hành không chặn phát triển mới trên main
• Nếu một thẻ beta đã được đẩy hoặc xuất bản và cần sửa, người bảo trì cắt thẻ -beta.N tiếp theo thay vì xóa hoặc tạo lại thẻ beta cũ
• Quy trình phát hành chi tiết, phê duyệt, thông tin xác thực và ghi chú khôi phục chỉ dành cho người bảo trì

​

Danh sách kiểm tra cho người vận hành phát hành

1. Bắt đầu từ main hiện tại: kéo bản mới nhất, xác nhận commit mục tiêu đã được đẩy, và xác nhận CI của main hiện tại đủ xanh để tạo nhánh từ đó.
2. Viết lại phần đầu của CHANGELOG.md từ lịch sử commit thực bằng /changelog, giữ các mục hướng tới người dùng, commit, đẩy, rồi rebase/pull thêm một lần trước khi tạo nhánh.
3. Xem lại các bản ghi tương thích phát hành trong src/plugins/compat/registry.ts và src/commands/doctor/shared/deprecation-compat.ts. Chỉ xóa tương thích đã hết hạn khi đường dẫn nâng cấp vẫn được bao phủ, hoặc ghi lại lý do vì sao nó được chủ ý giữ lại.
4. Tạo release/YYYY.M.D từ main hiện tại; không thực hiện công việc phát hành thông thường trực tiếp trên main.
5. Tăng mọi vị trí phiên bản bắt buộc cho thẻ dự định, rồi chạy pnpm release:prep. Lệnh này làm mới phiên bản Plugin, kho Plugin, lược đồ cấu hình, siêu dữ liệu cấu hình kênh được đóng gói, baseline tài liệu cấu hình, export Plugin SDK và baseline API Plugin SDK theo đúng thứ tự. Commit mọi drift được tạo trước khi gắn thẻ. Sau đó chạy preflight xác định cục bộ: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, và pnpm release:check.
6. Chạy OpenClaw NPM Release với preflight_only=true. Trước khi có thẻ, có thể dùng SHA đầy đủ 40 ký tự của nhánh phát hành cho preflight chỉ để xác thực. Lưu preflight_run_id thành công.
7. Khởi động tất cả kiểm thử trước phát hành bằng Full Release Validation cho nhánh phát hành, thẻ, hoặc SHA commit đầy đủ. Đây là entrypoint thủ công duy nhất cho bốn hộp kiểm thử phát hành lớn: Vitest, Docker, QA Lab và Package.
8. Nếu xác thực thất bại, sửa trên nhánh phát hành và chạy lại tệp, lane, job workflow, hồ sơ gói, nhà cung cấp hoặc allowlist mô hình nhỏ nhất đã thất bại để chứng minh bản sửa. Chỉ chạy lại toàn bộ umbrella khi bề mặt đã thay đổi khiến bằng chứng trước đó trở nên cũ.
9. Với beta, gắn thẻ vYYYY.M.D-beta.N, rồi chạy OpenClaw Release Publish từ nhánh release/YYYY.M.D tương ứng. Quy trình này xác minh pnpm plugins:sync:check, dispatch tất cả gói Plugin có thể xuất bản lên npm và cùng tập đó lên ClawHub song song, rồi quảng bá artifact preflight npm OpenClaw đã chuẩn bị với dist-tag tương ứng ngay khi xuất bản npm của Plugin thành công. Sau khi child xuất bản npm OpenClaw thành công, nó tạo hoặc cập nhật trang phát hành/phát hành trước GitHub tương ứng từ phần CHANGELOG.md khớp hoàn chỉnh. Các bản phát hành stable được xuất bản lên npm latest trở thành bản phát hành mới nhất trên GitHub; các bản phát hành bảo trì stable được giữ trên npm beta được tạo với GitHub latest=false. Xuất bản ClawHub vẫn có thể đang chạy trong khi npm OpenClaw xuất bản, nhưng workflow xuất bản phát hành in ID các lần chạy con ngay lập tức. Mặc định nó không chờ ClawHub sau khi dispatch, nên khả năng sẵn có của npm OpenClaw không bị chặn bởi phê duyệt ClawHub hoặc công việc registry chậm hơn; đặt wait_for_clawhub=true khi ClawHub phải chặn hoàn tất workflow. Đường dẫn ClawHub thử lại các lỗi cài đặt phụ thuộc CLI tạm thời, xuất bản các Plugin vượt qua preview ngay cả khi một ô preview bị lỗi không ổn định, và kết thúc bằng xác minh registry cho mọi phiên bản Plugin mong đợi để các lần xuất bản một phần vẫn hiển thị và có thể thử lại. Sau khi xuất bản, chạy pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> để xác minh bản phát hành trước trên GitHub, dist-tag npm beta, tính toàn vẹn npm, đường dẫn cài đặt đã xuất bản, phiên bản chính xác trên ClawHub, artifact ClawHub và kết luận workflow con từ một lệnh. Thêm --rerun-failed-clawhub khi sidecar ClawHub chỉ thất bại ở các job có thể thử lại và cần được chạy lại tại chỗ. Sau đó chạy kiểm thử chấp nhận gói sau xuất bản với gói openclaw@YYYY.M.D-beta.N hoặc openclaw@beta đã xuất bản. Nếu một bản phát hành trước đã được đẩy hoặc xuất bản cần sửa, hãy cắt số phát hành trước tương ứng tiếp theo; không xóa hoặc viết lại bản phát hành trước cũ.
10. Với stable, chỉ tiếp tục sau khi beta hoặc ứng viên phát hành đã được kiểm định có bằng chứng xác thực bắt buộc. Xuất bản npm stable cũng đi qua OpenClaw Release Publish, tái sử dụng artifact preflight thành công qua preflight_run_id; mức sẵn sàng phát hành macOS stable cũng yêu cầu .zip, .dmg, .dSYM.zip đã đóng gói và appcast.xml đã cập nhật trên main. Workflow xuất bản macOS riêng tư tự động xuất bản appcast đã ký lên main công khai sau khi asset phát hành được xác minh; nếu bảo vệ nhánh chặn push trực tiếp, nó mở hoặc cập nhật một PR appcast.
11. Sau khi xuất bản, chạy trình xác minh sau xuất bản npm, E2E Telegram published-npm độc lập tùy chọn khi bạn cần bằng chứng kênh sau xuất bản, quảng bá dist-tag khi cần, xác minh trang phát hành GitHub được tạo, và chạy các bước thông báo phát hành.

​

Preflight phát hành

• Chạy pnpm check:test-types trước preflight phát hành để TypeScript của kiểm thử vẫn được bao phủ bên ngoài cổng pnpm check cục bộ nhanh hơn
• Chạy pnpm check:architecture trước preflight phát hành để các kiểm tra chu kỳ import rộng hơn và ranh giới kiến trúc đều xanh bên ngoài cổng cục bộ nhanh hơn
• Chạy pnpm build && pnpm ui:build trước pnpm release:check để các artifact phát hành dist/* dự kiến và gói Control UI tồn tại cho bước xác thực pack
• Chạy pnpm release:prep sau khi tăng phiên bản gốc và trước khi gắn thẻ. Lệnh này chạy mọi bộ sinh phát hành tất định thường bị lệch sau thay đổi phiên bản/cấu hình/API: phiên bản Plugin, kiểm kê Plugin, schema cấu hình cơ sở, siêu dữ liệu cấu hình kênh đi kèm, baseline tài liệu cấu hình, export SDK Plugin, và baseline API SDK Plugin. pnpm release:check chạy lại các bộ bảo vệ đó ở chế độ kiểm tra và báo cáo mọi lỗi lệch phát sinh mà nó tìm thấy trong một lượt trước khi chạy kiểm tra phát hành package.
• Chạy workflow thủ công Full Release Validation trước khi phê duyệt phát hành để khởi động tất cả test box tiền phát hành từ một điểm vào. Workflow này nhận nhánh, thẻ, hoặc SHA commit đầy đủ, dispatch CI thủ công, và dispatch OpenClaw Release Checks cho install smoke, package acceptance, kiểm tra package đa hệ điều hành, tương đương QA Lab, Matrix, và các lane Telegram. Các lần chạy ổn định/mặc định giữ live/E2E đầy đủ và Docker release-path soak phía sau run_release_soak=true; release_profile=full bắt buộc bật soak. Với release_profile=full và rerun_group=all, nó cũng chạy package Telegram E2E dựa trên artifact release-package-under-test từ release checks. Cung cấp release_package_spec sau khi phát hành beta để dùng lại package npm đã ship trên release checks, Package Acceptance, và package Telegram E2E mà không cần dựng lại tarball phát hành. Chỉ cung cấp npm_telegram_package_spec khi Telegram cần dùng một package đã phát hành khác với phần còn lại của xác thực phát hành. Cung cấp package_acceptance_package_spec khi Package Acceptance cần dùng một package đã phát hành khác với release package spec. Cung cấp evidence_package_spec khi báo cáo bằng chứng riêng tư cần chứng minh rằng việc xác thực khớp với một package npm đã phát hành mà không ép chạy Telegram E2E. Ví dụ: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• Chạy workflow thủ công Package Acceptance khi bạn muốn bằng chứng kênh phụ cho một ứng viên package trong khi công việc phát hành tiếp tục. Dùng source=npm cho openclaw@beta, openclaw@latest, hoặc một phiên bản phát hành chính xác; source=ref để pack một nhánh/thẻ/SHA package_ref đáng tin cậy bằng harness workflow_ref hiện tại; source=url cho một tarball HTTPS với SHA-256 bắt buộc; hoặc source=artifact cho một tarball được tải lên bởi một lần chạy GitHub Actions khác. Workflow phân giải ứng viên thành package-under-test, dùng lại bộ lập lịch phát hành Docker E2E trên tarball đó, và có thể chạy Telegram QA trên cùng tarball với telegram_mode=mock-openai hoặc telegram_mode=live-frontier. Khi các lane Docker được chọn bao gồm published-upgrade-survivor, artifact package là ứng viên và published_upgrade_survivor_baseline chọn baseline đã phát hành. update-restart-auth dùng package ứng viên làm cả CLI đã cài đặt và package-under-test để nó kiểm thử đường dẫn khởi động lại được quản lý của lệnh cập nhật ứng viên. Ví dụ: gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai Hồ sơ phổ biến:
  • smoke: các lane cài đặt/kênh/agent, mạng Gateway, và tải lại cấu hình
  • package: các lane package/cập nhật/khởi động lại/Plugin nguyên bản theo artifact, không có OpenWebUI hoặc ClawHub live
  • product: hồ sơ package cộng với các kênh MCP, dọn dẹp cron/subagent, tìm kiếm web OpenAI, và OpenWebUI
  • full: các khối release-path Docker với OpenWebUI
  • custom: lựa chọn docker_lanes chính xác cho một lần chạy lại tập trung
• Chạy trực tiếp workflow thủ công CI khi bạn chỉ cần phạm vi bao phủ CI bình thường đầy đủ cho ứng viên phát hành. Các dispatch CI thủ công bỏ qua phạm vi thay đổi và bắt buộc chạy các shard Linux Node, shard Plugin đi kèm, hợp đồng kênh, tương thích Node 22, check, check-additional, build smoke, kiểm tra tài liệu, Python Skills, Windows, macOS, Android, và các lane i18n Control UI. Ví dụ: gh workflow run ci.yml --ref release/YYYY.M.D
• Chạy pnpm qa:otel:smoke khi xác thực telemetry phát hành. Lệnh này kiểm thử QA-lab thông qua một bộ nhận OTLP/HTTP cục bộ và xác minh tên span trace đã export, thuộc tính bị giới hạn, và biên tập lại nội dung/định danh mà không cần Opik, Langfuse, hoặc bộ thu thập bên ngoài khác.
• Chạy pnpm release:check trước mọi bản phát hành được gắn thẻ
• Chạy OpenClaw Release Publish cho chuỗi publish có thay đổi sau khi thẻ tồn tại. Dispatch nó từ release/YYYY.M.D (hoặc main khi publish một thẻ có thể truy cập từ main), truyền thẻ phát hành và preflight_run_id OpenClaw npm thành công, và giữ phạm vi publish Plugin mặc định all-publishable trừ khi bạn cố ý chạy sửa chữa tập trung. Workflow tuần tự hóa publish npm Plugin, publish ClawHub Plugin, và publish npm OpenClaw để package lõi không được publish trước các Plugin đã externalize của nó.
• Release checks hiện chạy trong một workflow thủ công riêng: OpenClaw Release Checks
• OpenClaw Release Checks cũng chạy lane tương đương mock QA Lab cộng với hồ sơ Matrix live nhanh và lane Telegram QA trước khi phê duyệt phát hành. Các lane live dùng môi trường qa-live-shared; Telegram cũng dùng lease thông tin xác thực Convex CI. Chạy workflow thủ công QA-Lab - All Lanes với matrix_profile=all và matrix_shards=true khi bạn muốn toàn bộ kiểm kê Matrix transport, media, và E2EE chạy song song.
• Xác thực runtime cài đặt và nâng cấp đa hệ điều hành là một phần của OpenClaw Release Checks công khai và Full Release Validation, vốn gọi trực tiếp workflow tái sử dụng .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Việc tách này là có chủ đích: giữ đường dẫn phát hành npm thật ngắn, tất định, và tập trung vào artifact, trong khi các kiểm tra live chậm hơn ở lane riêng để chúng không làm đình trệ hoặc chặn publish
• Các kiểm tra phát hành mang secret nên được dispatch thông qua Full Release Validation hoặc từ workflow ref main/release để logic workflow và secret vẫn được kiểm soát
• OpenClaw Release Checks nhận nhánh, thẻ, hoặc SHA commit đầy đủ miễn là commit đã phân giải có thể truy cập từ một nhánh OpenClaw hoặc thẻ phát hành
• Preflight chỉ xác thực OpenClaw NPM Release cũng nhận SHA commit đầy đủ 40 ký tự của nhánh workflow hiện tại mà không yêu cầu thẻ đã push
• Đường dẫn SHA đó chỉ dành cho xác thực và không thể được nâng cấp thành publish thật
• Ở chế độ SHA, workflow tổng hợp v<package.json version> chỉ cho kiểm tra siêu dữ liệu package; publish thật vẫn yêu cầu thẻ phát hành thật
• Cả hai workflow giữ đường dẫn publish và promotion thật trên runner do GitHub host, trong khi đường dẫn xác thực không thay đổi có thể dùng runner Linux Blacksmith lớn hơn
• Workflow đó chạy OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache bằng cả hai secret workflow OPENAI_API_KEY và ANTHROPIC_API_KEY
• Preflight phát hành npm không còn chờ lane release checks riêng biệt
• Trước khi gắn thẻ ứng viên phát hành cục bộ, chạy RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check. Helper này chạy các guardrail phát hành nhanh, kiểm tra phát hành npm/ClawHub Plugin, build, UI build, và release:openclaw:npm:check theo thứ tự bắt các lỗi thường chặn phê duyệt trước khi workflow publish GitHub bắt đầu.
• Chạy RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (hoặc thẻ beta/correction tương ứng) trước khi phê duyệt
• Sau khi publish npm, chạy node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (hoặc phiên bản beta/correction tương ứng) để xác minh đường dẫn cài đặt registry đã phát hành trong một prefix tạm mới
• Sau khi publish beta, chạy OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live để xác minh onboarding package đã cài đặt, thiết lập Telegram, và Telegram E2E thật dựa trên package npm đã phát hành bằng pool thông tin xác thực Telegram được lease dùng chung. Các lần chạy một lần cục bộ của maintainer có thể bỏ qua biến Convex và truyền trực tiếp ba thông tin xác thực env OPENCLAW_QA_TELEGRAM_*.
• Để chạy post-publish beta smoke đầy đủ từ máy maintainer, dùng pnpm release:beta-smoke -- --beta betaN. Helper này chạy xác thực cập nhật npm Parallels/fresh-target, dispatch NPM Telegram Beta E2E, thăm dò đúng lần chạy workflow, tải artifact xuống, và in báo cáo Telegram.
• Maintainer có thể chạy cùng kiểm tra post-publish từ GitHub Actions thông qua workflow thủ công NPM Telegram Beta E2E. Workflow này cố ý chỉ thủ công và không chạy trên mọi merge.
• Tự động hóa phát hành của maintainer hiện dùng preflight-rồi-promote:
  • publish npm thật phải vượt qua một npm preflight_run_id thành công
  • publish npm thật phải được dispatch từ cùng nhánh main hoặc release/YYYY.M.D với lần chạy preflight thành công
  • phát hành npm ổn định mặc định là beta
  • publish npm ổn định có thể nhắm rõ latest thông qua input workflow
  • thay đổi npm dist-tag dựa trên token hiện nằm trong openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml vì lý do bảo mật, vì npm dist-tag add vẫn cần NPM_TOKEN trong khi repo công khai giữ publish chỉ dùng OIDC
  • macOS Release công khai chỉ dành cho xác thực; khi một thẻ chỉ tồn tại trên nhánh phát hành nhưng workflow được dispatch từ main, đặt public_release_branch=release/YYYY.M.D
  • publish mac riêng tư thật phải vượt qua preflight_run_id và validate_run_id mac riêng tư thành công
  • các đường dẫn publish thật promote artifact đã chuẩn bị thay vì build lại chúng
• Với các bản phát hành sửa lỗi ổn định như YYYY.M.D-N, bộ xác minh post-publish cũng kiểm tra cùng đường dẫn nâng cấp prefix tạm từ YYYY.M.D lên YYYY.M.D-N để các bản sửa lỗi phát hành không thể âm thầm để các cài đặt global cũ ở payload ổn định cơ sở
• Preflight phát hành npm thất bại đóng trừ khi tarball bao gồm cả dist/control-ui/index.html và payload dist/control-ui/assets/ không rỗng để chúng ta không ship dashboard trình duyệt rỗng lần nữa
• Xác minh post-publish cũng kiểm tra rằng các entrypoint Plugin đã phát hành và siêu dữ liệu package có trong layout registry đã cài đặt. Một bản phát hành ship thiếu payload runtime Plugin sẽ thất bại ở bộ xác minh postpublish và không thể được promote lên latest.
• pnpm test:install:smoke cũng thực thi ngân sách unpackedSize của npm pack trên tarball cập nhật ứng viên, để e2e trình cài đặt bắt được việc pack phình to ngoài ý muốn trước đường dẫn publish phát hành
• Nếu công việc phát hành đã chạm vào lập kế hoạch CI, manifest thời gian extension, hoặc ma trận kiểm thử extension, hãy sinh lại và rà soát các output ma trận plugin-prerelease-extension-shard do planner sở hữu từ .github/workflows/plugin-prerelease.yml trước khi phê duyệt để ghi chú phát hành không mô tả một layout CI cũ
• Mức sẵn sàng phát hành macOS ổn định cũng bao gồm các bề mặt updater:
  • GitHub release cuối cùng phải có .zip, .dmg, và .dSYM.zip đã đóng gói
  • appcast.xml trên main phải trỏ đến zip ổn định mới sau khi publish; workflow publish macOS riêng tư tự động commit nó, hoặc mở PR appcast khi push trực tiếp bị chặn
  • app đã đóng gói phải giữ bundle id không debug, URL feed Sparkle không rỗng, và CFBundleVersion bằng hoặc cao hơn sàn build Sparkle chính tắc cho phiên bản phát hành đó

​

Các hộp kiểm thử phát hành

pnpm ci:full-release --sha <full-sha>

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 \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N

• minimum: đường dẫn OpenAI/core live và Docker quan trọng cho phát hành nhanh nhất
• stable: minimum cộng thêm độ phủ provider/backend ổn định để phê duyệt phát hành
• full: stable cộng thêm độ phủ provider/media tư vấn rộng

# Validate an unpublished release candidate branch.
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

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \
  -f npm_telegram_provider_mode=mock-openai

​

Vitest

• tóm tắt Full Release Validation hiển thị URL lần chạy CI đã dispatch
• lần chạy CI xanh trên SHA mục tiêu chính xác
• tên shard thất bại hoặc chậm từ các job CI khi điều tra hồi quy
• artifact thời gian Vitest như .artifacts/vitest-shard-timings.json khi một lần chạy cần phân tích hiệu năng

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

​

Docker

• kiểm tra smoke cài đặt đầy đủ với smoke cài đặt toàn cục Bun chậm được bật
• chuẩn bị/tái sử dụng ảnh smoke Dockerfile gốc theo SHA mục tiêu, với các job smoke QR, root/gateway, và installer/Bun chạy dưới dạng các shard install-smoke riêng
• các làn E2E kho lưu trữ
• các chunk Docker đường dẫn phát hành: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g, và plugins-runtime-install-h
• độ phủ OpenWebUI bên trong chunk plugins-runtime-services khi được yêu cầu
• các làn cài đặt/gỡ cài đặt Plugin đóng gói đã tách bundled-plugin-install-uninstall-0 đến bundled-plugin-install-uninstall-23
• các bộ provider live/E2E và độ phủ model live Docker khi release checks bao gồm các bộ live

​

QA Lab

• làn tương đương mock so sánh làn ứng viên OpenAI với baseline Opus 4.6 bằng gói tương đương agentic
• hồ sơ QA Matrix live nhanh dùng môi trường qa-live-shared
• làn QA Telegram live dùng các lease thông tin xác thực Convex CI
• pnpm qa:otel:smoke khi telemetry phát hành cần bằng chứng cục bộ rõ ràng

​

Gói

• source=npm: openclaw@beta, openclaw@latest, hoặc một phiên bản phát hành OpenClaw chính xác
• source=ref: đóng gói nhánh, thẻ hoặc SHA commit đầy đủ package_ref đáng tin cậy với harness workflow_ref đã chọn
• source=url: tải xuống .tgz HTTPS với package_sha256 bắt buộc
• source=artifact: tái sử dụng .tgz được tải lên bởi một lần chạy GitHub Actions khác

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

• smoke: các lane cài đặt gói/channel/agent, mạng Gateway và tải lại cấu hình nhanh
• package: hợp đồng cài đặt/cập nhật/khởi động lại/gói Plugin cộng với bằng chứng cài đặt Skills ClawHub trực tiếp; đây là mặc định của kiểm tra phát hành
• product: package cộng với channel MCP, dọn dẹp cron/subagent, tìm kiếm web OpenAI và OpenWebUI
• full: các phần đường dẫn phát hành Docker với OpenWebUI
• custom: danh sách docker_lanes chính xác cho các lần chạy lại tập trung

​

Tự động hóa phát hành

1. Checkout tag phát hành và phân giải commit SHA của tag đó.
2. Xác minh tag có thể truy cập từ main hoặc release/*.
3. Chạy pnpm plugins:sync:check.
4. Dispatch Plugin NPM Release với publish_scope=all-publishable và ref=<release-sha>.
5. Dispatch Plugin ClawHub Release với cùng scope và SHA.
6. Dispatch OpenClaw NPM Release với tag phát hành, dist-tag npm và preflight_run_id đã lưu.

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest

​

Đầu vào workflow NPM

• tag: tag phát hành bắt buộc như v2026.4.2, v2026.4.2-1 hoặc v2026.4.2-beta.1; khi preflight_only=true, nó cũng có thể là commit SHA đầy đủ 40 ký tự hiện tại của nhánh workflow để chỉ xác thực preflight
• preflight_only: true chỉ để xác thực/bản dựng/gói, false cho đường dẫn phát hành thật
• preflight_run_id: bắt buộc trên đường dẫn phát hành thật để workflow tái sử dụng tarball đã chuẩn bị từ lần chạy preflight thành công
• npm_dist_tag: tag đích npm cho đường dẫn phát hành; mặc định là beta

• tag: tag phát hành bắt buộc; phải đã tồn tại
• preflight_run_id: id lần chạy preflight OpenClaw NPM Release thành công; bắt buộc khi publish_openclaw_npm=true
• npm_dist_tag: tag đích npm cho gói OpenClaw
• plugin_publish_scope: mặc định là all-publishable; chỉ dùng selected cho công việc sửa chữa tập trung
• plugins: tên gói @openclaw/* phân tách bằng dấu phẩy khi plugin_publish_scope=selected
• publish_openclaw_npm: mặc định là true; chỉ đặt false khi dùng workflow làm bộ điều phối sửa chữa chỉ dành cho Plugin
• wait_for_clawhub: mặc định là false để khả dụng npm không bị sidecar ClawHub chặn; chỉ đặt true khi việc hoàn tất workflow phải bao gồm hoàn tất ClawHub

• ref: nhánh, tag hoặc commit SHA đầy đủ để xác thực. Các kiểm tra mang secret yêu cầu commit đã phân giải có thể truy cập từ một nhánh OpenClaw hoặc tag phát hành.
• run_release_soak: chọn tham gia soak live/E2E toàn diện, đường dẫn phát hành Docker và upgrade-survivor từ trước đến nay trên các kiểm tra phát hành ổn định/mặc định. Tùy chọn này bị buộc bật bởi release_profile=full.

• Tag ổn định và tag sửa lỗi có thể phát hành lên beta hoặc latest
• Tag prerelease beta chỉ có thể phát hành lên beta
• Với OpenClaw NPM Release, đầu vào commit SHA đầy đủ chỉ được phép khi preflight_only=true
• OpenClaw Release Checks và Full Release Validation luôn chỉ xác thực
• Đường dẫn phát hành thật phải dùng cùng npm_dist_tag đã dùng trong preflight; workflow xác minh metadata đó trước khi tiếp tục phát hành

​

Trình tự phát hành npm ổn định

1. Chạy OpenClaw NPM Release với preflight_only=true
   • Trước khi có tag, bạn có thể dùng commit SHA đầy đủ hiện tại của nhánh workflow để chạy thử không phát hành chỉ nhằm xác thực workflow preflight
2. Chọn npm_dist_tag=beta cho luồng beta trước thông thường, hoặc latest chỉ khi bạn cố ý muốn phát hành ổn định trực tiếp
3. Chạy Full Release Validation trên nhánh phát hành, tag phát hành hoặc commit SHA đầy đủ khi bạn muốn CI thông thường cộng với phạm vi live prompt cache, Docker, QA Lab, Matrix và Telegram từ một workflow thủ công
4. Nếu bạn cố ý chỉ cần đồ thị kiểm thử thông thường xác định, hãy chạy workflow CI thủ công trên ref phát hành
5. Lưu preflight_run_id thành công
6. Chạy OpenClaw Release Publish với cùng tag, cùng npm_dist_tag và preflight_run_id đã lưu; nó phát hành các Plugin đã tách ra bên ngoài lên npm và ClawHub trước khi quảng bá gói npm OpenClaw
7. Nếu bản phát hành được đưa lên beta, dùng workflow riêng tư openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml để quảng bá phiên bản ổn định đó từ beta lên latest
8. Nếu bản phát hành cố ý được phát hành trực tiếp lên latest và beta phải theo cùng bản dựng ổn định ngay lập tức, dùng cùng workflow riêng tư đó để trỏ cả hai dist-tag vào phiên bản ổn định, hoặc để đồng bộ tự phục hồi theo lịch của nó chuyển beta sau

​

Tham chiếu công khai

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

​

Liên quan

• Channel phát hành