Release and CI

การตรวจสอบความถูกต้องของรุ่นเผยแพร่ฉบับเต็ม

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

เรียกใช้งานจาก workflow ref ที่เชื่อถือได้ ซึ่งโดยปกติคือ main และส่งสาขาการเผยแพร่ แท็ก หรือ 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

provider ยังยอมรับ anthropic หรือ minimax สำหรับการเริ่มต้นใช้งานข้ามระบบปฏิบัติการ และรอบการทำงานของเอเจนต์แบบต้นทางถึงปลายทาง งานลูกที่นำกลับมาใช้ซ้ำได้จะระบุ harness ของเวิร์กโฟลว์ที่ถูกเรียกจาก job.workflow_repository และ job.workflow_sha ส่วนอินพุต ref จะเลือกตัวเลือกที่จะทดสอบ วิธีนี้ทำให้ตรรกะการตรวจสอบปัจจุบันที่เชื่อถือได้ ยังคงพร้อมใช้งานเมื่อตรวจสอบสาขาหรือแท็กการเผยแพร่รุ่นเก่า

เวิร์กโฟลว์ลูกทุกตัวที่ถูกสั่งให้ทำงานต้องรายงาน workflow SHA เดียวกับการรันแม่ Full Release Validation หาก main เปลี่ยนแปลงระหว่างการสั่งให้เวิร์กโฟลว์แม่และลูก ทำงาน กรอบรวมจะล้มเหลวแบบปิดแม้ว่าเวิร์กโฟลว์ลูกจะสำเร็จก็ตาม สำหรับการพิสูจน์ด้วย commit ที่แน่นอนและเปลี่ยนแปลงไม่ได้ ให้ใช้ pnpm ci:full-release --sha <target-sha> ตัวช่วยจะสร้าง ref ชั่วคราว release-ci/* ที่ตรึงไว้กับ origin/main ปัจจุบันซึ่งเชื่อถือได้ ส่ง SHA เป้าหมาย เป็น ref ของตัวเลือกเท่านั้น นำหลักฐานแบบเป้าหมายตรงกันอย่างเคร่งครัดกลับมาใช้ใหม่ เมื่อมี และลบ ref หลังการตรวจสอบ ส่ง -f reuse_evidence=false เพื่อบังคับให้รันใหม่ หรือ --workflow-sha <trusted-main-sha> เพื่อเลือก commit ของเวิร์กโฟลว์รุ่นเก่าที่ยังคง เข้าถึงได้จาก origin/main ปัจจุบัน ตัวเวิร์กโฟลว์เองจะไม่สร้างหรืออัปเดต ref ของที่เก็บโค้ด

release_profile=stable และ release_profile=full จะรันการทดสอบต่อเนื่องแบบ live/Docker อย่างละเอียดครบถ้วนเสมอ ส่ง run_release_soak=true เพื่อรวมชุดการทดสอบ ต่อเนื่องเดียวกันไว้ในโปรไฟล์ beta การเผยแพร่แบบเสถียรจะปฏิเสธ manifest การตรวจสอบ ที่ไม่มีการทดสอบต่อเนื่องนี้และหลักฐานประสิทธิภาพผลิตภัณฑ์แบบบังคับ

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

ขั้นตอนระดับบนสุด

สำหรับ rerun_group=all งาน Check for reusable validation evidence จะทำงานก่อน: งานนี้ค้นหาการตรวจสอบเต็มรูปแบบครั้งก่อนล่าสุดที่สำเร็จ สำหรับ SHA เป้าหมาย โปรไฟล์การเผยแพร่ การตั้งค่าการทดสอบต่อเนื่องที่มีผล และอินพุตการตรวจสอบที่ตรงกัน ทุกประการ เมื่อมีหลักฐานดังกล่าว ระบบจะข้ามทุกชุดการทดสอบ และตัวตรวจสอบกรอบรวม จะตรวจสอบอาร์ติแฟกต์แม่ที่เปลี่ยนแปลงไม่ได้ การรันเวิร์กโฟลว์ลูก และบันทึกการสั่งงาน อีกครั้ง กลไกนี้มีไว้เพื่อกู้คืนการรันซ้ำของตัวเลือกเดียวกันเท่านั้น ไม่อนุญาตให้นำ หลักฐานข้าม SHA มาใช้ใหม่ สำหรับตัวเลือกที่เปลี่ยนแปลง ให้รันเกตของแพ็กเกจ อาร์ติแฟกต์ การติดตั้ง Docker หรือผู้ให้บริการทั้งหมดที่ได้รับผลกระทบจากความแตกต่างนั้น ใหม่ ส่ง reuse_evidence=false เพื่อบังคับให้รันเต็มรูปแบบใหม่ การนำหลักฐานกลับมา ใช้ใหม่จะทำงานเฉพาะจาก main หรือ ref release-ci/* มาตรฐานที่ตรึงด้วย SHA ซึ่ง commit ของเวิร์กโฟลว์ยังคงอยู่ในสายประวัติของ main ที่เชื่อถือได้ ส่วน workflow ref อื่นจะรันชุดการทดสอบที่เลือกใหม่

นอกจากนี้ สำหรับ rerun_group=all งาน Verify Docker runtime image assets จะสร้าง เป้าหมาย Docker runtime-assets โดยใช้ OPENCLAW_EXTENSIONS=diagnostics-otel,codex งานนี้ทำงานขนานกับขั้นตอนอื่น และถูกบังคับใช้โดยตัวตรวจสอบกรอบรวม ชุดการทดสอบจะไม่รอให้งานนี้เสร็จก่อนเริ่มสั่งงาน อีกต่อไป rerun_group ที่แคบกว่าจะข้ามการตรวจสอบเบื้องต้นนี้

ขั้นตอน	รายละเอียด
การระบุเป้าหมาย	งาน: `Resolve target ref`
เวิร์กโฟลว์ลูก: ไม่มี
พิสูจน์ว่า: ระบุสาขาการเผยแพร่ แท็ก หรือ commit SHA แบบเต็ม และบันทึกอินพุตที่เลือกไว้
การรันใหม่: รันกรอบรวมใหม่หากขั้นตอนนี้ล้มเหลว
การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ Docker	งาน: `Verify Docker runtime image assets`
เวิร์กโฟลว์ลูก: ไม่มี
พิสูจน์ว่า: เป้าหมายการสร้าง Docker `runtime-assets` ยังคงสำเร็จก่อนสั่งให้ขั้นตอนอื่นทำงาน ทำงานเฉพาะเมื่อ `rerun_group=all`
การรันใหม่: รันกรอบรวมใหม่โดยใช้ `rerun_group=all`
Vitest และ CI ปกติ	งาน: `Run normal full CI`
เวิร์กโฟลว์ลูก: `CI`
พิสูจน์ว่า: กราฟ CI เต็มรูปแบบแบบแมนนวลทำงานกับ ref เป้าหมาย รวมถึงชุดการทดสอบ Linux Node, ส่วนแบ่ง Plugin ที่รวมมาให้, ส่วนแบ่งสัญญาของ Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, `check-`, `check-additional-`, การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ที่สร้างแล้ว, การตรวจสอบเอกสาร, Skills ของ Python, Windows, macOS, การรองรับหลายภาษาของ Control UI และ Android ผ่านกรอบรวม
การรันใหม่: `rerun_group=ci`
การตรวจสอบ Plugin ก่อนเผยแพร่	งาน: `Run plugin prerelease validation`
เวิร์กโฟลว์ลูก: `Plugin Prerelease`
พิสูจน์ว่า: การตรวจสอบแบบสแตติกของ Plugin เฉพาะช่วงเผยแพร่ ความครอบคลุมของ Plugin แบบเอเจนต์ ส่วนแบ่งชุดการทดสอบ Plugin เต็มรูปแบบ ชุดการทดสอบ Docker ก่อนเผยแพร่สำหรับ Plugin และอาร์ติแฟกต์ `plugin-inspector-advisory` แบบไม่บังคับสำหรับการคัดแยกปัญหาความเข้ากันได้
การรันใหม่: `rerun_group=plugin-prerelease`
การตรวจสอบการเผยแพร่	งาน: `Run release/live/Docker/QA validation`
เวิร์กโฟลว์ลูก: `OpenClaw Release Checks`
พิสูจน์ว่า: การตรวจสอบเบื้องต้นของการติดตั้ง การตรวจสอบแพ็กเกจข้ามระบบปฏิบัติการ Package Acceptance ความสอดคล้องกับ QA Lab, Matrix แบบ live และ Telegram แบบ live โปรไฟล์เสถียรและเต็มรูปแบบยังรันชุดการทดสอบ live/E2E อย่างละเอียดครบถ้วนและส่วนย่อยของ Docker ในเส้นทางการเผยแพร่ ส่วนเบตาสามารถเลือกเข้าร่วมด้วย `run_release_soak=true`
การรันใหม่: `rerun_group=release-checks` หรือแฮนเดิล release-checks ที่แคบกว่า
แพ็กเกจ Telegram	งาน: `Run package Telegram E2E`
เวิร์กโฟลว์ลูก: `NPM Telegram Beta E2E`
พิสูจน์ว่า: การทดสอบ Telegram E2E ที่เน้นเฉพาะแพ็กเกจที่เผยแพร่แล้ว เมื่อกำหนด `release_package_spec` หรือ `npm_telegram_package_spec` การตรวจสอบตัวเลือกเต็มรูปแบบจะใช้การทดสอบ Telegram E2E มาตรฐานของ Package Acceptance แทน
การรันใหม่: `rerun_group=npm-telegram` พร้อม `release_package_spec` หรือ `npm_telegram_package_spec`
ประสิทธิภาพผลิตภัณฑ์	งาน: `Run product performance evidence`
เวิร์กโฟลว์ลูก: `OpenClaw Performance`
พิสูจน์ว่า: การรันประสิทธิภาพตามโปรไฟล์การเผยแพร่ (`profile=release`, `repeat=3`, `fail_on_regression=true`, `publish_reports=false`) กับ SHA เป้าหมาย เอาต์พุต Kova จะคงอยู่ในอาร์ติแฟกต์ของเวิร์กโฟลว์ และเวิร์กโฟลว์ลูกต้องพิสูจน์ว่างานเผยแพร่รายงานถูกข้าม จำเป็นและเป็นเงื่อนไขบังคับเฉพาะสำหรับ `rerun_group=all` หรือ `rerun_group=performance`; ไม่จำเป็นสำหรับกลุ่มการรันใหม่ที่แคบกว่า
การรันใหม่: `rerun_group=performance`
ตัวตรวจสอบกรอบรวม	งาน: `Verify full validation`
เวิร์กโฟลว์ลูก: ไม่มี
พิสูจน์ว่า: ตรวจสอบผลลัพธ์ที่บันทึกไว้ของการรันเวิร์กโฟลว์ลูกอีกครั้ง และเพิ่มตารางงานที่ใช้เวลานานที่สุดจากเวิร์กโฟลว์ลูก
การรันใหม่: หลังรันเวิร์กโฟลว์ลูกที่ล้มเหลวใหม่จนสำเร็จแล้ว ให้รันใหม่เฉพาะงานนี้

กรอบรวมจะสั่งให้การทดสอบประสิทธิภาพผลิตภัณฑ์ทำงานในโหมดอาร์ติแฟกต์เท่านั้นเสมอ OpenClaw Performance อนุญาตให้เผยแพร่รายงานเฉพาะการรันตามกำหนดเวลา หรือการสั่งงาน แบบแมนนวลที่ตั้งค่า publish_reports=true อย่างชัดเจน เกตสำหรับโหมดอาร์ติแฟกต์เท่านั้น ต้องทำงานสำเร็จ เพื่อพิสูจน์ว่างานผู้เผยแพร่ยังคงถูกข้าม หลักฐานทั้งแบบใหม่และแบบ นำกลับมาใช้ใหม่จะบันทึก controls.performanceReportPublication=artifact-only; ตัวตรวจสอบและตัวเลือก การนำหลักฐานกลับมาใช้ใหม่จะปฏิเสธหลักฐานที่ไม่มีการพิสูจน์จากเวิร์กโฟลว์ลูกด้าน ประสิทธิภาพที่ผ่านการปรับรูปแบบและตรงกัน

ตัวตรวจสอบจะอัปโหลด manifest มาตรฐานเป็น full-release-validation-<run-id>-<run-attempt> เครื่องมือหลักฐานจะตรวจสอบ รหัสอาร์ติแฟกต์ ค่าไดเจสต์ การรันที่สร้าง และความพยายาม ก่อนดาวน์โหลดอาร์ติแฟกต์ ตามรหัสที่แน่นอนนั้น เครื่องมือจะจำกัดขนาด ZIP ที่ดาวน์โหลด ตรวจสอบไบต์ของไฟล์กับ ค่าไดเจสต์ REST sha256: และสตรีมรายการ manifest แบบมีขอบเขตเพียงรายการเดียว ที่อนุญาต โดยไม่แตกไฟล์เก็บถาวร นามแฝงชื่อคงที่จะยังคงอยู่ชั่วคราวสำหรับผู้ใช้ การเผยแพร่รุ่นเก่า ตัวตรวจสอบจะเลือกอาร์ติแฟกต์ที่มีข้อมูลความพยายามกำกับก่อนเสมอ ในช่วงเปลี่ยนผ่าน ระบบจะยอมรับชื่อคงที่เฉพาะสำหรับผู้สร้าง manifest v2 ในความพยายาม ครั้งที่ 1 เท่านั้น และจะปฏิเสธชื่อแบบเดิมสำหรับความพยายามครั้งหลังและ manifest v3

สำหรับ ref=main ที่ใช้ rerun_group=all, สำหรับ ref release/* และสำหรับ ref รุ่นอัลฟาของ Tideclaw การรันกรอบรวมที่ใหม่กว่าจะแทนที่การรันเก่าที่มี ref และกลุ่ม การรันใหม่เดียวกัน เมื่อเวิร์กโฟลว์แม่ถูกยกเลิก ตัวติดตามของมันจะยกเลิกเวิร์กโฟลว์ลูก ทั้งหมดที่สั่งให้ทำงานไปแล้ว การตรวจสอบด้วยแท็กและ SHA ที่ตรึงไว้จะไม่ยกเลิกกันเอง

ขั้นตอนการตรวจสอบการเผยแพร่

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

ขั้นตอน	รายละเอียด
เป้าหมายการเผยแพร่	งาน: `Resolve target ref`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: ref ที่เลือก, SHA ที่คาดไว้ซึ่งระบุหรือไม่ก็ได้, โปรไฟล์, กลุ่มการรันซ้ำ และตัวกรองชุดทดสอบแบบสดเฉพาะจุด
การรันซ้ำ: `rerun_group=release-checks`
อาร์ติแฟกต์แพ็กเกจ	งาน: `Prepare release package artifact`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: แพ็กหรือค้นหา tarball ตัวเลือกหนึ่งรายการ และอัปโหลด `release-package-under-test` สำหรับการตรวจสอบที่เกี่ยวข้องกับแพ็กเกจในขั้นตอนถัดไป
การรันซ้ำ: กลุ่มแพ็กเกจ, ข้ามระบบปฏิบัติการ หรือแบบสด/E2E ที่ได้รับผลกระทบ
การทดสอบติดตั้งเบื้องต้น	งาน: `Run install smoke`
เวิร์กโฟลว์รองรับ: `Install Smoke`
การทดสอบ: เส้นทางการติดตั้งแบบเต็มพร้อมการใช้ smoke image จาก Dockerfile รากซ้ำ, การติดตั้งแพ็กเกจ QR, การทดสอบ Docker เบื้องต้นสำหรับรากและ Gateway, การทดสอบ Docker ของตัวติดตั้ง และการทดสอบเบื้องต้นของผู้ให้บริการอิมเมจผ่านการติดตั้ง Bun แบบโกลบอล
การรันซ้ำ: `rerun_group=install-smoke`
ข้ามระบบปฏิบัติการ	งาน: `cross_os_release_checks`
เวิร์กโฟลว์รองรับ: `OpenClaw Cross-OS Release Checks (Reusable)`
การทดสอบ: เลนการติดตั้งใหม่และอัปเกรดบน Linux, Windows และ macOS สำหรับผู้ให้บริการและโหมดที่เลือก โดยใช้ tarball ตัวเลือกพร้อมแพ็กเกจพื้นฐาน
การรันซ้ำ: `rerun_group=cross-os`
E2E ของที่เก็บและแบบสด	งาน: `Run repo/live E2E validation`
เวิร์กโฟลว์รองรับ: `OpenClaw Live And E2E Checks (Reusable)`
การทดสอบ: E2E ของที่เก็บ, แคชแบบสด, การสตรีม OpenAI ผ่าน websocket, ชาร์ดผู้ให้บริการแบบสดเนทีฟและ Plugin และชุดทดสอบจำลองโมเดล/แบ็กเอนด์/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`
การทดสอบ: ฟิกซ์เจอร์แพ็กเกจ Plugin แบบออฟไลน์, การอัปเดต Plugin, E2E แพ็กเกจ Telegram กับ OpenAI จำลองตามมาตรฐาน และการตรวจสอบความอยู่รอดหลังอัปเกรดจากเวอร์ชันที่เผยแพร่โดยใช้ tarball เดียวกัน การตรวจสอบการเผยแพร่ที่มีผลบังคับใช้จะใช้เวอร์ชันพื้นฐานล่าสุดที่เผยแพร่เป็นค่าเริ่มต้น ส่วนการตรวจสอบแบบแช่ (`run_release_soak=true`) จะขยายไปยังรุ่นเสถียร 4 รุ่นล่าสุดบน npm และเวอร์ชันย้อนหลังที่ปักหมุดไว้ 3 เวอร์ชัน (`2026.4.23`, `2026.5.2`, `2026.4.15`) โดยทำงานกับฟิกซ์เจอร์อัปเกรดจากปัญหาที่มีการรายงาน
การรันซ้ำ: `rerun_group=package`
สกอร์การ์ดระดับความพร้อม	งาน: `Render maturity scorecard release docs`
เวิร์กโฟลว์รองรับ: `maturity-scorecard.yml`
การทดสอบ: เรนเดอร์เอกสารสกอร์การ์ดระดับความพร้อมเพื่อเป็นคำแนะนำกับ ref เป้าหมาย ทำงานเฉพาะเมื่อส่ง `run_maturity_scorecard=true` เท่านั้น
การรันซ้ำ: `rerun_group=qa` พร้อม `run_maturity_scorecard=true`
ความเท่าเทียมของ QA	งาน: `Run QA Lab parity lane` และ `Run QA Lab parity report`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: ชุดความเท่าเทียมแบบเอเจนต์สำหรับตัวเลือกและเวอร์ชันพื้นฐาน จากนั้นจึงสร้างรายงานความเท่าเทียม
การรันซ้ำ: `rerun_group=qa-parity` หรือ `rerun_group=qa`
ความเท่าเทียมของรันไทม์ QA	งาน: `Run QA Lab runtime parity lane`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: เลนความเท่าเทียมแบบเอเจนต์สำหรับคู่รันไทม์ `openclaw`/`codex` (`pnpm openclaw qa suite --runtime-pair openclaw,codex`) ซึ่งรวมระดับมาตรฐาน และเมื่อใช้ `run_release_soak=true` จะรวมระดับการทดสอบแบบแช่ด้วย เป็นเพียงคำแนะนำ: ความล้มเหลวแต่ละรายการจะไม่ขัดขวางตัวตรวจสอบการเผยแพร่
การรันซ้ำ: `rerun_group=qa-parity` หรือ `rerun_group=qa`
ความครอบคลุมเครื่องมือรันไทม์ QA	งาน: `Enforce QA Lab runtime tool coverage`
เวิร์กโฟลว์รองรับ: งานโดยตรง
การทดสอบ: ความคลาดเคลื่อนของเครื่องมือแบบไดนามิกระหว่าง `openclaw` และ `codex` ในระดับความเท่าเทียมของรันไทม์มาตรฐาน (`pnpm openclaw qa coverage --tools`) โดยใช้ผลลัพธ์จากเลนความเท่าเทียมของรันไทม์ QA มีผลบังคับใช้: งานนี้ไม่สามารถยกเว้นให้เป็นเพียงคำแนะนำได้
การรันซ้ำ: `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`
เวิร์กโฟลว์รองรับ: ไม่มี
การทดสอบ: งานตรวจสอบการเผยแพร่ที่จำเป็นสำหรับกลุ่มการรันซ้ำที่เลือก
การรันซ้ำ: รันซ้ำหลังจากงานย่อยเฉพาะจุดผ่านแล้ว

ส่วนย่อยเส้นทางเผยแพร่ Docker

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

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

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

โปรไฟล์การเผยแพร่

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

โปรไฟล์	การใช้งานที่กำหนดไว้	ขอบเขตการทดสอบสด/ผู้ให้บริการที่รวมไว้
`beta`	การทดสอบควันที่สำคัญต่อรีลีสและรวดเร็วที่สุด	เส้นทางสดของ OpenAI/แกนหลัก, โมเดลสดบน Docker สำหรับ OpenAI, แกนหลัก Gateway แบบเนทีฟ, โปรไฟล์ Gateway ของ OpenAI แบบเนทีฟ, Plugin OpenAI แบบเนทีฟ และ Gateway สดของ OpenAI บน Docker
`stable`	โปรไฟล์เริ่มต้นสำหรับการอนุมัติรีลีส	`beta` พร้อมการทดสอบควันของ Anthropic, Google, MiniMax, แบ็กเอนด์, ชุดทดสอบสดแบบเนทีฟ, แบ็กเอนด์ CLI สดบน Docker, การผูก ACP บน Docker, ชุดทดสอบ Codex บน Docker, การประกาศเอเจนต์ย่อยบน Docker และชาร์ดการทดสอบควัน OpenCode Go
`full`	การตรวจสอบเชิงแนะนำในวงกว้าง	`stable` พร้อมผู้ให้บริการเชิงแนะนำ, ชาร์ดการทดสอบสดของ Plugin และชาร์ดการทดสอบสื่อแบบสด

ส่วนเพิ่มเติมเฉพาะ full

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

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

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

การเรียกใช้ซ้ำแบบเจาะจง

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

แฮนเดิล	ขอบเขต
`all`	ทุกขั้นตอนของการตรวจสอบรีลีสแบบเต็ม
`ci`	เฉพาะเวิร์กโฟลว์ลูก CI แบบเต็มที่เรียกใช้ด้วยตนเอง
`plugin-prerelease`	เฉพาะเวิร์กโฟลว์ลูกสำหรับการทดสอบก่อนรีลีสของ Plugin
`release-checks`	ทุกขั้นตอนการตรวจสอบรีลีสของ OpenClaw
`install-smoke`	การทดสอบควันของการติดตั้งต่อเนื่องไปจนถึงการตรวจสอบรีลีส
`cross-os`	การตรวจสอบรีลีสข้ามระบบปฏิบัติการ
`live-e2e`	การทดสอบ E2E ของรีโพซิทอรี/แบบสด และการตรวจสอบเส้นทางรีลีสด้วย Docker
`package`	การยอมรับแพ็กเกจ
`qa`	ความสอดคล้องของ QA พร้อมเลน QA แบบสด
`qa-parity`	เฉพาะเลนและรายงานความสอดคล้องของ QA
`qa-live`	Matrix/Telegram แบบสดของ QA พร้อมเลน Discord, WhatsApp และ Slack ที่มีการควบคุมเมื่อเปิดใช้งาน
`npm-telegram`	การทดสอบ E2E ของ Telegram สำหรับแพ็กเกจที่เผยแพร่แล้ว ต้องใช้ `release_package_spec` หรือ `npm_telegram_package_spec`
`performance`	เฉพาะหลักฐานประสิทธิภาพของผลิตภัณฑ์

ใช้ live_suite_filter ร่วมกับ rerun_group=live-e2e เมื่อชุดทดสอบสดชุดใดชุดหนึ่งล้มเหลว รหัสตัวกรองที่ใช้ได้ถูกกำหนดไว้ในเวิร์กโฟลว์การทดสอบสด/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 เป็นแฮนเดิลรวมสำหรับเรียกใช้ซ้ำของ ชาร์ดผู้ให้บริการทั้งสาม ดังนั้นจึงยังคงกระจายงานไปยังงาน Gateway เชิงแนะนำบน Docker ทั้งหมด

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

ความล้มเหลวของการตรวจสอบรีลีสของ QA จะขัดขวางการตรวจสอบรีลีสตามปกติ การตรวจสอบขอบเขตเครื่องมือ รันไทม์ของ QA (ความคลาดเคลื่อนแบบไดนามิกของเครื่องมือระหว่าง openclaw และ codex ใน ระดับมาตรฐาน) จะขัดขวางตัวตรวจสอบการตรวจสอบรีลีสด้วย แม้ว่าเลนความสอดคล้องของรันไทม์ QA ที่อยู่เบื้องหลังจะเป็นเพียงเชิงแนะนำก็ตาม การเรียกใช้ Tideclaw alpha อาจยังคง ถือว่าเลนการตรวจสอบรีลีสที่ไม่เกี่ยวกับความปลอดภัยของแพ็กเกจเป็นเชิงแนะนำ เมื่อใช้ release_profile=beta ชุดทดสอบผู้ให้บริการแบบสดของ Run repo/live E2E validation จะเป็นเชิงแนะนำ เนื่องจากการติดตั้งใช้งานโมเดลของบุคคลที่สามเปลี่ยนแปลงได้ระหว่างการทำรีลีส ดังนั้น beta จะแสดงความล้มเหลวเหล่านี้เป็นคำเตือน ขณะที่โปรไฟล์ stable และ full ยังคงให้ความล้มเหลวดังกล่าวขัดขวางการทำงาน เมื่อ live_suite_filter ร้องขอเลน QA แบบสดที่มีการควบคุมอย่างชัดเจน เช่น Discord, WhatsApp หรือ Slack จะต้องเปิดใช้ตัวแปรรีโพซิทอรี 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 ของการยอมรับแพ็กเกจและอาร์ติแฟกต์การยอมรับของ Docker
อาร์ติแฟกต์การตรวจสอบรีลีสข้ามระบบปฏิบัติการสำหรับแต่ละระบบปฏิบัติการและชุดทดสอบ
อาร์ติแฟกต์ความสอดคล้องของ QA, ความสอดคล้องของรันไทม์, 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/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

Was this useful?