Release and CI

การตรวจสอบความถูกต้องของรีลีสเต็มรูปแบบ

Full Release Validation คือร่มใหญ่ของการปล่อยรุ่น เป็น entrypoint แบบแมนนวลเพียงจุดเดียว สำหรับหลักฐานก่อนปล่อยรุ่น แต่งานส่วนใหญ่เกิดขึ้นในเวิร์กโฟลว์ลูก เพื่อให้กล่องที่ล้มเหลว สามารถรันซ้ำได้โดยไม่ต้องเริ่มการปล่อยรุ่นทั้งหมดใหม่

รันจาก ref ของเวิร์กโฟลว์ที่เชื่อถือได้ โดยปกติคือ main และส่ง branch, tag, หรือ full commit SHA ของรุ่นที่จะปล่อยเป็น ref:

bash

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

เวิร์กโฟลว์ลูกใช้ ref ของเวิร์กโฟลว์ที่เชื่อถือได้สำหรับ harness และใช้ input ref สำหรับ candidate ที่กำลังทดสอบ วิธีนี้ทำให้ตรรกะการตรวจสอบใหม่พร้อมใช้งาน เมื่อกำลังตรวจสอบ branch หรือ tag ของรุ่นเก่า

release_profile=stable และ release_profile=full จะรัน live/Docker soak แบบละเอียดครบถ้วนเสมอ ส่ง run_release_soak=true เพื่อรวม soak lanes เดียวกัน กับโปรไฟล์ beta การเผยแพร่ stable จะปฏิเสธ validation manifest ที่ไม่มี soak นี้ และไม่มีหลักฐาน product-performance ที่เป็นตัวบล็อก

Package Acceptance โดยปกติจะสร้าง tarball ของ candidate จาก ref ที่ resolve แล้ว รวมถึงรันแบบ full-SHA ที่ dispatch ด้วย pnpm ci:full-release หลังจากเผยแพร่ beta แล้ว ให้ส่ง release_package_spec=openclaw@YYYY.M.PATCH-beta.N เพื่อใช้แพ็กเกจ npm ที่ส่งมอบแล้ว ซ้ำใน release checks, Package Acceptance, cross-OS, release-path Docker และ package Telegram ใช้ package_acceptance_package_spec เฉพาะเมื่อ Package Acceptance ควรพิสูจน์แพ็กเกจอื่นโดยเจตนา lane ของแพ็กเกจ live สำหรับ Plugin Codex จะตามสถานะเดียวกัน: ค่า release_package_spec ที่เผยแพร่แล้วจะ derive codex_plugin_spec=npm:@openclaw/codex@<version>; รันแบบ SHA/artifact จะ pack extensions/codex จาก ref ที่เลือก; และผู้ปฏิบัติงาน สามารถตั้ง codex_plugin_spec โดยตรงสำหรับแหล่ง Plugin แบบ npm:, npm-pack:, หรือ git: lane จะให้การอนุมัติการติดตั้ง Codex CLI แบบชัดเจนที่ Plugin นั้นต้องใช้ จากนั้นรัน Codex CLI preflight และเทิร์นของ agent OpenAI ในเซสชันเดียวกัน

สเตจระดับบนสุด

สเตจ	รายละเอียด
การ resolve เป้าหมาย	Job: `Resolve target ref`
เวิร์กโฟลว์ลูก: ไม่มี
พิสูจน์: resolve release branch, tag, หรือ full commit SHA และบันทึก input ที่เลือกไว้
รันซ้ำ: รัน umbrella ซ้ำหากขั้นตอนนี้ล้มเหลว
Vitest และ CI ปกติ	Job: `Run normal full CI`
เวิร์กโฟลว์ลูก: `CI`
พิสูจน์: กราฟ full CI แบบแมนนวลกับ target ref รวมถึง Linux Node lanes, bundled plugin shards, plugin and channel contract shards, ความเข้ากันได้กับ Node 22, `check-`, `check-additional-`, smoke checks ของ built-artifact, checks เอกสาร, Python skills, Windows, macOS, Control UI i18n และ Android ผ่าน umbrella
รันซ้ำ: `rerun_group=ci`
Plugin prerelease	Job: `Run plugin prerelease validation`
เวิร์กโฟลว์ลูก: `Plugin Prerelease`
พิสูจน์: release-only plugin static checks, agentic plugin coverage, full extension batch shards, plugin prerelease Docker lanes และ artifact `plugin-inspector-advisory` แบบไม่บล็อกสำหรับ triage ความเข้ากันได้
รันซ้ำ: `rerun_group=plugin-prerelease`
Release checks	Job: `Run release/live/Docker/QA validation`
เวิร์กโฟลว์ลูก: `OpenClaw Release Checks`
พิสูจน์: install smoke, cross-OS package checks, Package Acceptance, QA Lab parity, live Matrix และ live Telegram โปรไฟล์ stable และ full ยังรัน live/E2E suites แบบละเอียดครบถ้วนและ Docker release-path chunks ด้วย; beta สามารถเลือกเปิดใช้ด้วย `run_release_soak=true`
รันซ้ำ: `rerun_group=release-checks` หรือ handle release-checks ที่แคบกว่า
Package Telegram	Job: `Run package Telegram E2E`
เวิร์กโฟลว์ลูก: `NPM Telegram Beta E2E`
พิสูจน์: Telegram E2E แบบโฟกัสสำหรับแพ็กเกจที่เผยแพร่แล้วเมื่อมีการตั้ง `release_package_spec` หรือ `npm_telegram_package_spec` การตรวจสอบ candidate แบบเต็มใช้ Package Acceptance Telegram E2E ตาม canonical แทน
รันซ้ำ: `rerun_group=npm-telegram` พร้อม `release_package_spec` หรือ `npm_telegram_package_spec`
ตัวตรวจสอบ umbrella	Job: `Verify full validation`
เวิร์กโฟลว์ลูก: ไม่มี
พิสูจน์: ตรวจซ้ำผลสรุปของรันเวิร์กโฟลว์ลูกที่บันทึกไว้ และผนวกตาราง job ที่ช้าที่สุดจากเวิร์กโฟลว์ลูก
รันซ้ำ: รันเฉพาะ job นี้ซ้ำหลังจากรันเวิร์กโฟลว์ลูกที่ล้มเหลวให้เขียวแล้ว

สำหรับ ref=main และ rerun_group=all umbrella ที่ใหม่กว่าจะ supersede อันเก่า เมื่อ parent ถูกยกเลิก monitor ของมันจะยกเลิกเวิร์กโฟลว์ลูกใด ๆ ที่ dispatch ไปแล้ว รันการตรวจสอบ release branch และ tag จะไม่ยกเลิกกันเองโดยค่าเริ่มต้น

สเตจ Release checks

OpenClaw Release Checks เป็นเวิร์กโฟลว์ลูกที่ใหญ่ที่สุด โดย resolve เป้าหมาย หนึ่งครั้งและเตรียม artifact release-package-under-test ที่แชร์ร่วมกันเมื่อสเตจ ที่เกี่ยวกับแพ็กเกจหรือ Docker ต้องใช้

ขั้นตอน	รายละเอียด
เป้าหมายรีลีส	งาน: `Resolve target ref`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: ref ที่เลือก, SHA ที่คาดไว้ซึ่งเป็นทางเลือก, โปรไฟล์, กลุ่มการรันซ้ำ, และตัวกรองชุดทดสอบสดแบบเจาะจง
รันซ้ำ: `rerun_group=release-checks`
อาร์ติแฟกต์แพ็กเกจ	งาน: `Prepare release package artifact`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: แพ็กหรือ resolve tarball ผู้สมัครหนึ่งรายการ แล้วอัปโหลด `release-package-under-test` สำหรับการตรวจสอบปลายน้ำที่เกี่ยวกับแพ็กเกจ
รันซ้ำ: กลุ่มแพ็กเกจ, ข้ามระบบปฏิบัติการ, หรือ live/E2E ที่ได้รับผลกระทบ
ควันทดสอบการติดตั้ง	งาน: `Run install smoke`
เวิร์กโฟลว์รองรับ: `Install Smoke`
การทดสอบ: เส้นทางการติดตั้งเต็มรูปแบบพร้อมการนำอิมเมจควันทดสอบ Dockerfile รากกลับมาใช้, การติดตั้งแพ็กเกจ QR, ควันทดสอบ Docker ของรากและ Gateway, การทดสอบ Docker ของตัวติดตั้ง, ควันทดสอบ Bun global install image-provider, และ E2E การติดตั้ง/ถอนการติดตั้ง bundled-Plugin แบบเร็ว
รันซ้ำ: `rerun_group=install-smoke`
ข้ามระบบปฏิบัติการ	งาน: `cross_os_release_checks`
เวิร์กโฟลว์รองรับ: `OpenClaw Cross-OS Release Checks (Reusable)`
การทดสอบ: เลนแบบสดใหม่และอัปเกรดบน Linux, Windows, และ macOS สำหรับผู้ให้บริการและโหมดที่เลือก โดยใช้ tarball ผู้สมัครร่วมกับแพ็กเกจ baseline
รันซ้ำ: `rerun_group=cross-os`
E2E ของ repo และแบบสด	งาน: `Run repo/live E2E validation`
เวิร์กโฟลว์รองรับ: `OpenClaw Live And E2E Checks (Reusable)`
การทดสอบ: E2E ของ repository, แคชสด, การสตรีม websocket ของ OpenAI, ชาร์ดผู้ให้บริการและ Plugin แบบ native live, และ harness ของโมเดล/backend/gateway แบบสดที่รองรับด้วย Docker ซึ่งเลือกโดย `release_profile`
รัน: `run_release_soak=true`, `release_profile=full`, หรือ `rerun_group=live-e2e` แบบเจาะจง
รันซ้ำ: `rerun_group=live-e2e`, พร้อม `live_suite_filter` ได้ตามต้องการ
เส้นทางรีลีส Docker	งาน: `Run Docker release-path validation`
เวิร์กโฟลว์รองรับ: `OpenClaw Live And E2E Checks (Reusable)`
การทดสอบ: ชังก์ Docker ของเส้นทางรีลีสเทียบกับอาร์ติแฟกต์แพ็กเกจที่ใช้ร่วมกัน
รัน: `run_release_soak=true`, `release_profile=full`, หรือ `rerun_group=live-e2e` แบบเจาะจง
รันซ้ำ: `rerun_group=live-e2e`
การยอมรับแพ็กเกจ	งาน: `Run package acceptance`
เวิร์กโฟลว์รองรับ: `Package Acceptance`
การทดสอบ: fixture แพ็กเกจ Plugin แบบออฟไลน์, การอัปเดต Plugin, E2E แพ็กเกจ mock-OpenAI Telegram แบบ canonical, และการตรวจสอบการอยู่รอดของ published-upgrade เทียบกับ tarball เดียวกัน การตรวจสอบรีลีสแบบบล็อกใช้ baseline เผยแพร่ล่าสุดตามค่าเริ่มต้น; การตรวจสอบแบบ soak ขยายเป็นทุกรีลีส npm แบบ stable ตั้งแต่ `2026.4.23` เป็นต้นไป รวมถึง fixture ของปัญหาที่รายงาน
รันซ้ำ: `rerun_group=package`
ความเท่าเทียม QA	งาน: `Run QA Lab parity lane` และ `Run QA Lab parity report`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: แพ็ก parity แบบ agentic ของผู้สมัครและ baseline แล้วตามด้วยรายงาน parity
รันซ้ำ: `rerun_group=qa-parity` หรือ `rerun_group=qa`
Matrix แบบสดของ QA	งาน: `Run QA Lab live Matrix lane`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: โปรไฟล์ QA Matrix แบบสดและเร็วในสภาพแวดล้อม `qa-live-shared`
รันซ้ำ: `rerun_group=qa-live` หรือ `rerun_group=qa`
Telegram แบบสดของ QA	งาน: `Run QA Lab live Telegram lane`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: QA Telegram แบบสดด้วยการเช่าข้อมูลรับรอง Convex CI
รันซ้ำ: `rerun_group=qa-live` หรือ `rerun_group=qa`
ตัวตรวจสอบรีลีส	งาน: `Verify release checks`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: งาน release-check ที่จำเป็นสำหรับกลุ่มการรันซ้ำที่เลือก
รันซ้ำ: รันซ้ำหลังจากงานลูกแบบเจาะจงผ่าน

ชังก์เส้นทางรีลีส Docker

ขั้นตอนเส้นทางรีลีส Docker จะรันชังก์เหล่านี้เมื่อ live_suite_filter ว่างเปล่า:

ชังก์	ความครอบคลุม
`core`	เลนควันทดสอบเส้นทางรีลีส Docker หลัก
`package-update-openai`	พฤติกรรมการติดตั้ง/อัปเดตแพ็กเกจ OpenAI, การติดตั้ง Codex ตามต้องการ, เทิร์นสดของ Codex Plugin, และการเรียกเครื่องมือ Chat Completions
`package-update-anthropic`	พฤติกรรมการติดตั้งและอัปเดตแพ็กเกจ Anthropic
`package-update-core`	พฤติกรรมแพ็กเกจและการอัปเดตที่ไม่ผูกกับผู้ให้บริการ
`plugins-runtime-plugins`	เลน runtime ของ Plugin ที่ทดสอบพฤติกรรม Plugin
`plugins-runtime-services`	เลน runtime ของ Plugin ที่รองรับด้วยบริการและแบบสด; รวม OpenWebUI เมื่อมีการร้องขอ
`plugins-runtime-install-a` ถึง `plugins-runtime-install-h`	ชุดการติดตั้ง/runtime ของ Plugin ที่แบ่งเพื่อการตรวจสอบรีลีสแบบขนาน

ใช้ docker_lanes=<lane[,lane]> แบบเจาะจงบนเวิร์กโฟลว์ live/E2E ที่ใช้ซ้ำได้เมื่อ มีเลน Docker เพียงเลนเดียวที่ล้มเหลว อาร์ติแฟกต์รีลีสมีคำสั่งรันซ้ำแยกตามเลน พร้อมอินพุตสำหรับอาร์ติแฟกต์แพ็กเกจและการนำอิมเมจกลับมาใช้เมื่อมีให้ใช้งาน

โปรไฟล์รีลีส

release_profile ควบคุมขอบเขต live/provider ภายในการตรวจสอบรีลีสเป็นหลัก ไม่ได้ลบ CI เต็มรูปแบบปกติ, ก่อนรีลีส Plugin, ควันทดสอบการติดตั้ง, การยอมรับ แพ็กเกจ, หรือ QA Lab โปรไฟล์ stable และ full จะรัน repo/live E2E แบบละเอียดครบถ้วนและความครอบคลุม soak ของเส้นทางรีลีส Docker เสมอ โปรไฟล์ beta สามารถเลือกเข้าร่วมได้ด้วย run_release_soak=true การยอมรับแพ็กเกจให้ E2E Telegram ของแพ็กเกจแบบ canonical สำหรับผู้สมัครแบบเต็มทุกรายการ ดังนั้น umbrella จึงไม่ทำซ้ำ live poller นั้น

โปรไฟล์	การใช้งานที่ตั้งใจ	ความครอบคลุม live/provider ที่รวมอยู่
`minimum`	ควันทดสอบที่สำคัญต่อรีลีสและเร็วที่สุด	เส้นทาง live ของ OpenAI/core, โมเดล live ของ Docker สำหรับ OpenAI, gateway หลักแบบ native, โปรไฟล์ gateway OpenAI แบบ native, Plugin OpenAI แบบ native, และ gateway OpenAI แบบ live ของ Docker
`stable`	โปรไฟล์อนุมัติรีลีสเริ่มต้น	`minimum` รวมถึงควันทดสอบ Anthropic, Google, MiniMax, backend, harness การทดสอบ native live, backend CLI แบบ live ของ Docker, bind ACP ของ Docker, harness Codex ของ Docker, และชาร์ดควันทดสอบ OpenCode Go
`full`	การกวาดตรวจ advisory แบบกว้าง	`stable` รวมถึงผู้ให้บริการ advisory, ชาร์ด live ของ Plugin, และชาร์ด live ของสื่อ

ส่วนเพิ่มเติมสำหรับ full เท่านั้น

ชุดทดสอบเหล่านี้ถูกข้ามโดย stable และรวมอยู่ใน full:

พื้นที่	ความครอบคลุมเฉพาะ full
โมเดล live ของ Docker	OpenCode Go, OpenRouter, xAI, Z.ai, และ Fireworks
gateway live ของ Docker	ผู้ให้บริการ advisory ที่แบ่งเป็นชาร์ด DeepSeek/Fireworks, OpenCode Go/OpenRouter, และ xAI/Z.ai
โปรไฟล์ผู้ให้บริการ gateway แบบ native	ชาร์ด Anthropic Opus และ Sonnet/Haiku แบบเต็ม, Fireworks, DeepSeek, ชาร์ดโมเดล OpenCode Go แบบเต็ม, OpenRouter, xAI, และ Z.ai
ชาร์ด live ของ Plugin แบบ native	Plugins A-K, L-N, O-Z อื่นๆ, Moonshot, และ xAI
ชาร์ด live ของสื่อแบบ native	กลุ่มเสียง, เพลง Google, เพลง MiniMax, และวิดีโอ A-D

stable รวม native-live-src-gateway-profiles-anthropic-smoke และ native-live-src-gateway-profiles-opencode-go-smoke; full ใช้ชาร์ดโมเดล Anthropic และ OpenCode Go ที่กว้างกว่าแทน การรันซ้ำแบบเจาะจงยังสามารถใช้ handle รวม native-live-src-gateway-profiles-anthropic หรือ native-live-src-gateway-profiles-opencode-go ได้

การรันซ้ำแบบเจาะจง

ใช้ rerun_group เพื่อหลีกเลี่ยงการรันกล่องรีลีสที่ไม่เกี่ยวข้องซ้ำ:

แฮนเดิล	ขอบเขต
`all`	ทุกขั้นตอนของ Full Release Validation
`ci`	เฉพาะลูก Manual full CI เท่านั้น
`plugin-prerelease`	เฉพาะลูก Plugin Prerelease เท่านั้น
`release-checks`	ทุกขั้นตอนของ OpenClaw Release Checks
`install-smoke`	Install Smoke ผ่าน release checks
`cross-os`	การตรวจสอบรีลีสข้ามระบบปฏิบัติการ
`live-e2e`	การตรวจสอบ Repo/live E2E และเส้นทางรีลีส Docker
`package`	Package Acceptance
`qa`	QA parity รวมถึงเลน QA live
`qa-parity`	เฉพาะเลนและรายงาน QA parity
`qa-live`	QA live Matrix/Telegram รวมถึงเลน Discord, WhatsApp และ Slack ที่มีเกต เมื่อเปิดใช้งาน
`npm-telegram`	E2E ของ Telegram สำหรับแพ็กเกจที่เผยแพร่แล้ว ต้องมี `release_package_spec` หรือ `npm_telegram_package_spec`

ใช้ live_suite_filter ร่วมกับ rerun_group=live-e2e เมื่อชุด live หนึ่งชุดล้มเหลว รหัสตัวกรองที่ใช้ได้ถูกกำหนดไว้ในเวิร์กโฟลว์ live/E2E ที่นำกลับมาใช้ซ้ำได้ ซึ่งรวมถึง 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 และ live-codex-harness-docker

แฮนเดิล live-gateway-advisory-docker เป็นแฮนเดิลรันซ้ำแบบรวมสำหรับชาร์ดผู้ให้บริการสามรายการของมัน ดังนั้นยังคงกระจายงานไปยังงาน advisory Docker gateway ทั้งหมด

ใช้ cross_os_suite_filter ร่วมกับ rerun_group=cross-os เมื่อเลนข้ามระบบปฏิบัติการหนึ่งเลน ล้มเหลว ตัวกรองรับรหัส OS, รหัสชุดทดสอบ หรือคู่ OS/ชุดทดสอบ เช่น windows/packaged-upgrade, windows หรือ packaged-fresh สรุป Cross-OS มีเวลาต่อเฟสสำหรับเลน packaged upgrade และคำสั่งที่รันนาน จะพิมพ์บรรทัด Heartbeat เพื่อให้เห็นการอัปเดต Windows ที่ค้างอยู่ก่อน งานหมดเวลา

ความล้มเหลวของ QA release-check จะบล็อกการตรวจสอบรีลีสปกติ การ drift ของ dynamic tool ของ OpenClaw ที่จำเป็นในเทียร์มาตรฐานจะบล็อกตัวตรวจสอบ release-check เช่นกัน การรัน Tideclaw alpha อาจยังถือว่าเลน release-check ที่ไม่ใช่ package-safety เป็น advisory ได้ เมื่อ live_suite_filter ร้องขอเลน QA live ที่มีเกตอย่างชัดเจน เช่น Discord, WhatsApp หรือ Slack ตัวแปร repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED ที่ตรงกันต้องเปิดใช้งาน มิฉะนั้น การจับอินพุตจะล้มเหลวแทนที่จะข้ามเลนนั้นอย่างเงียบ ๆ รัน rerun_group=qa, qa-parity หรือ qa-live ซ้ำเมื่อคุณต้องการหลักฐาน QA ใหม่

หลักฐานที่ควรเก็บ

เก็บสรุป Full Release Validation ไว้เป็นดัชนีระดับรีลีส สรุปนี้ลิงก์ รหัสการรันลูกและมีตารางงานที่ช้าที่สุด สำหรับความล้มเหลว ให้ตรวจสอบเวิร์กโฟลว์ลูก ก่อน แล้วจึงรันแฮนเดิลที่ตรงกันและเล็กที่สุดด้านบนซ้ำ

อาร์ติแฟกต์ที่มีประโยชน์:

release-package-under-test จาก OpenClaw Release Checks
อาร์ติแฟกต์เส้นทางรีลีส Docker ภายใต้ .artifacts/docker-tests/
package-under-test ของ Package Acceptance และอาร์ติแฟกต์การยอมรับ Docker
อาร์ติแฟกต์ release-check ข้ามระบบปฏิบัติการสำหรับแต่ละ OS และชุดทดสอบ
อาร์ติแฟกต์ QA parity, Matrix และ Telegram

ไฟล์เวิร์กโฟลว์

.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

Was this useful?