Release and CI
การตรวจสอบความถูกต้องของรุ่นที่เผยแพร่แบบเต็มรูปแบบ
Full Release Validation เป็นกรอบรวมสำหรับการตรวจสอบความถูกต้องของผลิตภัณฑ์ก่อนเผยแพร่ งานส่วนใหญ่
เกิดขึ้นในเวิร์กโฟลว์ย่อย เพื่อให้สามารถรันกล่องที่ล้มเหลวซ้ำได้โดยไม่ต้องเริ่ม
การเผยแพร่ทั้งหมดใหม่ รันการเตรียมเผยแพร่ก่อนตรึง Code SHA ขั้นตอนนี้
จะรีเฟรชผลลัพธ์ภาษาของ Control UI เมื่อบอตเบื้องหลังยังไม่ได้ผสานผลลัพธ์
จากนั้นบังคับใช้การตรวจสอบแบบเข้มงวดว่าต้องไม่มี fallback เช่นเดียวกับที่ CI สำหรับการเผยแพร่ใช้
ตรึงคอมมิตก่อน changelog ที่ผลิตภัณฑ์เสร็จสมบูรณ์เป็น Code SHA แล้วรัน:
pnpm ci:full-release \ --sha <code-sha> \ --target-ref release/YYYY.M.PATCHprovider ยังยอมรับ anthropic หรือ minimax สำหรับการเริ่มต้นใช้งานข้ามระบบปฏิบัติการและ
รอบการทำงานของเอเจนต์แบบต้นทางถึงปลายทาง ตัวช่วยจะอนุมานโปรไฟล์ beta จากเวอร์ชันแพ็กเกจ alpha/beta
และใช้ stable ในกรณีอื่น ส่งอินพุตเวิร์กโฟลว์ทางเลือกด้วย
-f key=value; ใช้ -f release_profile=full เฉพาะสำหรับการกวาดตรวจคำแนะนำแบบครอบคลุม
ตัวช่วยจะสร้าง ref ชั่วคราว release-ci/* ซึ่งตรึงไว้กับ
SHA ของเวิร์กโฟลว์ origin/main ที่เชื่อถือได้หนึ่งรายการ ส่ง SHA เป้าหมายเป็นเพียง candidate ref
และลบ ref ชั่วคราวหลังการตรวจสอบความถูกต้อง เวิร์กโฟลว์ย่อยทุกตัวที่ถูกสั่งให้ทำงานต้อง
รายงาน SHA ของเวิร์กโฟลว์เดียวกันนั้น ส่ง
-f reuse_evidence=false เพื่อบังคับให้รันใหม่ หรือ
--workflow-sha <trusted-main-sha> เพื่อเลือกคอมมิตเวิร์กโฟลว์ที่เก่ากว่าซึ่งยัง
เข้าถึงได้จาก origin/main ปัจจุบัน เวิร์กโฟลว์จะไม่สร้างหรืออัปเดต
ref ของรีโพซิทอรีด้วยตนเอง
เมื่อ Code SHA ผ่านทั้งหมดแล้ว ให้สร้างและคอมมิตเฉพาะ CHANGELOG.md คอมมิตใหม่
นี้คือ Release SHA รันตัวช่วยเดิมสำหรับ Release SHA หลักฐานของผลิตภัณฑ์
จะถูกนำกลับมาใช้เฉพาะเมื่อ GitHub พิสูจน์ว่า Release SHA สืบทอดมาจาก
Code SHA และชุดพาธที่เปลี่ยนแปลงทั้งหมดตรงกับ CHANGELOG.md ทุกประการ; การตรวจสอบล่วงหน้าของ npm
และการยอมรับแพ็กเกจ/การติดตั้งยังคงรันบน Release SHA
release_profile=stable และ release_profile=full จะรัน
การทดสอบแช่ live/Docker แบบครบถ้วนเสมอ ส่ง run_release_soak=true เพื่อรวมเลนการทดสอบแช่เดียวกัน
กับโปรไฟล์ beta การเผยแพร่แบบ stable จะปฏิเสธแมนิเฟสต์การตรวจสอบความถูกต้อง
ที่ไม่มีการทดสอบแช่นี้และหลักฐานประสิทธิภาพผลิตภัณฑ์แบบบล็อก
โดยปกติ Package Acceptance จะสร้าง tarball ของ candidate จาก
ref ที่แก้ค่าแล้ว รวมถึงการรันด้วย SHA เต็มที่สั่งผ่าน pnpm ci:full-release หลังจาก
เผยแพร่ beta แล้ว ให้ส่ง 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 ในเซสชันเดียวกัน
รอบสุดท้ายซึ่งไม่มีการลองใหม่และใช้การคิดระดับปานกลาง จะส่งความคืบหน้าที่มองเห็นได้โดยละ
Codex final ไว้ อ่านอินพุตแบบสุ่มจากเวิร์กสเปซ เขียนอาร์ติแฟกต์ตามนั้นทุกประการ
และส่งการแจ้งว่าเสร็จสิ้นอย่างชัดแจ้ง วิธีนี้ตรวจจับการถดถอยใน v2026.7.1 ซึ่ง
การส่งความคืบหน้าตามปกติทำให้รอบการทำงานสิ้นสุดลง
ขั้นตอนระดับบนสุด
สำหรับ rerun_group=all งาน Check for reusable validation evidence จะรัน
ก่อน โดยค้นหาการตรวจสอบความถูกต้องแบบเต็มครั้งก่อนล่าสุดที่ผ่านทั้งหมด ซึ่งมีโปรไฟล์การเผยแพร่
การตั้งค่าการทดสอบแช่ที่มีผล และอินพุตการตรวจสอบความถูกต้องเดียวกัน การรันเป้าหมายเดิมซ้ำจะใช้
exact-target-full-validation-v1 เป้าหมายลูกหลานที่ผลต่างทั้งหมดตรงกับ
CHANGELOG.md ทุกประการจะใช้ changelog-only-release-v1; เลนผลิตภัณฑ์ทุกเลนจะถูกข้าม
และตัวตรวจสอบจะตรวจสอบการเปรียบเทียบคอมมิตของ GitHub, อาร์ติแฟกต์แม่ที่เปลี่ยนแปลงไม่ได้,
การรันย่อย และบันทึกการสั่งทำงานอีกครั้งอย่างเป็นอิสระ การเปลี่ยนเป้าหมายรูปแบบอื่นต้องใช้
การตรวจสอบ Code SHA ใหม่ ส่ง reuse_evidence=false เพื่อบังคับให้รันแบบเต็ม
ใหม่ การนำหลักฐานกลับมาใช้จะทำงานเฉพาะจาก main หรือ ref
release-ci/* แบบมาตรฐานที่ตรึงด้วย SHA ซึ่งคอมมิตเวิร์กโฟลว์ยังอยู่ในสายสืบทอด
main ที่เชื่อถือได้; ref เวิร์กโฟลว์อื่นจะรันเลนที่เลือกใหม่
การตรวจสอบใหม่ที่เกี่ยวข้องกับแพ็กเกจจะเตรียม tarball ที่เปลี่ยนแปลงไม่ได้หนึ่งรายการพร้อมอาร์ติแฟกต์ อิมเมจ Docker หนึ่งรายการก่อนสั่งให้ Plugin Prerelease และ OpenClaw Release Checks ทำงาน เวิร์กโฟลว์ย่อยทั้งสองจะตรวจสอบ SHA ของแพ็กเกจ, ID อาร์ติแฟกต์, ไดเจสต์บริการ, ครั้งที่พยายามรันของผู้สร้าง และไดเจสต์ของอาร์ไคฟ์ Docker ชุดเดียวกันก่อนใช้ เลเยอร์ Docker เปล่า ที่ไม่ขึ้นกับแพ็กเกจใช้แคช GHCR ที่ระบุตำแหน่งด้วยเนื้อหา; อิมเมจเฉพาะ candidate ยังคงเป็นอาร์ติแฟกต์ GitHub ที่เปลี่ยนแปลงไม่ได้ การรันแบบเจาะจงที่ระบุข้อกำหนดของแพ็กเกจ ที่เผยแพร่แล้วอย่างชัดเจนจะใช้พาธแพ็กเกจเดิมต่อไปแทน
นอกจากนี้ สำหรับ rerun_group=all งาน Verify Docker runtime image assets จะสร้าง
เป้าหมาย Docker runtime-assets ด้วย
OPENCLAW_EXTENSIONS=diagnostics-otel,codex งานนี้รันขนานกับ
ขั้นตอนอื่นและถูกบังคับใช้โดยตัวตรวจสอบกรอบรวม; เลนต่าง ๆ จะไม่รอให้
งานนี้เสร็จก่อนสั่งทำงานอีกต่อไป rerun_group ที่มีขอบเขตแคบกว่าจะข้ามการตรวจสอบล่วงหน้านี้
| ขั้นตอน | รายละเอียด |
|---|---|
| การแก้ค่าเป้าหมาย | งาน: Resolve target ref |
| เวิร์กโฟลว์ย่อย: ไม่มี | |
| พิสูจน์ว่า: แก้ค่าแบรนช์การเผยแพร่ แท็ก หรือ SHA ของคอมมิตแบบเต็ม และบันทึกอินพุตที่เลือกไว้ | |
| การรันซ้ำ: รันกรอบรวมซ้ำหากขั้นตอนนี้ล้มเหลว | |
| candidate ที่ใช้ร่วมกัน | งาน: Prepare shared release candidate |
เวิร์กโฟลว์ย่อย: OpenClaw Live And E2E Checks (Reusable) |
|
| พิสูจน์ว่า: จัดแพ็กและตรวจสอบแพ็กเกจของ SHA ที่แน่นอนหนึ่งรายการ สร้างอิมเมจ Docker ที่ใช้งานได้หนึ่งรายการ และบันทึกทูเพิลของอาร์ติแฟกต์แพ็กเกจและอิมเมจที่เปลี่ยนแปลงไม่ได้สำหรับเวิร์กโฟลว์ย่อยที่เกี่ยวข้องกับแพ็กเกจทั้งสองรายการ | |
| การรันซ้ำ: รันกลุ่มแพ็กเกจ, plugin-prerelease, ข้ามระบบปฏิบัติการ หรือ live/E2E ที่ได้รับผลกระทบซ้ำ | |
| การตรวจสอบล่วงหน้าของแอสเซ็ต 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, i18n ของ 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 และ Telegram แบบ live รวมถึงเลน Discord, WhatsApp และ Slack สำหรับคำแนะนำซึ่งมีการควบคุม โปรไฟล์ stable และ full ยังรันชุด live/E2E แบบครบถ้วนและส่วน Docker ของพาธการเผยแพร่; beta สามารถเลือกเข้าร่วมด้วย run_release_soak=true |
|
การรันซ้ำ: rerun_group=release-checks หรือแฮนเดิล release-checks ที่แคบกว่า |
|
| Telegram ของแพ็กเกจ | งาน: Run package Telegram E2E |
เวิร์กโฟลว์ย่อย: NPM Telegram Beta E2E |
|
พิสูจน์ว่า: E2E ของ Telegram ที่เจาะจงสำหรับแพ็กเกจที่เผยแพร่แล้ว เมื่อมีการตั้งค่า release_package_spec หรือ npm_telegram_package_spec การตรวจสอบ candidate แบบเต็มจะใช้ E2E ของ Telegram ใน 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; ตัวตรวจสอบและ
ตัวเลือกการนำกลับมาใช้จะปฏิเสธหลักฐานที่ไม่มีข้อพิสูจน์จากเวิร์กโฟลว์ย่อยด้านประสิทธิภาพ
ซึ่งปรับให้อยู่ในรูปแบบมาตรฐานและตรงกัน
ตัวตรวจสอบจะอัปโหลดแมนิเฟสต์มาตรฐานเป็น
full-release-validation-<run-id>-<run-attempt> เครื่องมือจัดการหลักฐานจะตรวจสอบ
ID อาร์ติแฟกต์ ไดเจสต์ การรันของผู้สร้าง และครั้งที่พยายาม ก่อนดาวน์โหลดตาม
ID อาร์ติแฟกต์นั้นอย่างแม่นยำ เครื่องมือจะจำกัดขนาด ZIP ที่ดาวน์โหลด ตรวจสอบไบต์เทียบกับไดเจสต์
sha256: จาก REST และสตรีมรายการแมนิเฟสต์ที่มีขอบเขตจำกัดเพียงรายการเดียวที่อนุญาต โดยไม่
แตกไฟล์อาร์ไคฟ์ นามแฝงชื่อแบบคงที่จะยังคงอยู่ชั่วคราวสำหรับผู้ใช้ผลลัพธ์การเผยแพร่รุ่นเก่า
ตัวตรวจสอบจะเลือกใช้อาร์ติแฟกต์ที่มีหมายเลขครั้งที่พยายามเสมอ; ในช่วงเปลี่ยนผ่าน
ตัวตรวจสอบจะยอมรับชื่อแบบคงที่เฉพาะสำหรับผู้สร้างแมนิเฟสต์ v2 ในครั้งที่พยายาม 1
และจะปฏิเสธชื่อแบบเดิมนั้นสำหรับครั้งที่พยายามหลังจากนั้นและแมนิเฟสต์ v3
สำหรับ ref=main ที่ใช้ rerun_group=all, สำหรับ ref ของ release/* และสำหรับ ref อัลฟาของ Tideclaw
การรันแบบครอบคลุมที่ใหม่กว่าจะแทนที่การรันที่เก่ากว่าซึ่งมี ref และ
กลุ่มการรันซ้ำเดียวกัน เมื่อรายการแม่ถูกยกเลิก ตัวตรวจสอบของรายการนั้นจะยกเลิก workflow ลูกใดๆ
ที่ได้ส่งไปแล้ว การรันตรวจสอบแท็กและ SHA ที่ปักหมุดไว้จะไม่
ยกเลิกกัน
ขั้นตอนการตรวจสอบรีลีส
OpenClaw Release Checks เป็น workflow ลูกที่ใหญ่ที่สุด โดยจะระบุเป้าหมาย
เพียงครั้งเดียวและตรวจสอบอาร์ติแฟกต์แพ็กเกจที่ใช้ร่วมกันของการรันแบบครอบคลุมเมื่อมี
การส่งโดยตรงหรือแบบเจาะจงจะจัดเตรียมอาร์ติแฟกต์ release-package-under-test
ของตนเองเมื่อขั้นตอนที่เกี่ยวข้องกับแพ็กเกจหรือ Docker ต้องใช้งาน
| ขั้นตอน | รายละเอียด |
|---|---|
| เป้าหมายรีลีส | งาน: Resolve target ref |
| workflow เบื้องหลัง: ไม่มี | |
| การทดสอบ: ref ที่เลือก, SHA ที่คาดหวังซึ่งระบุหรือไม่ก็ได้, โปรไฟล์, กลุ่มการรันซ้ำ และตัวกรองชุดทดสอบสดแบบเจาะจง | |
การรันซ้ำ: rerun_group=release-checks |
|
| อาร์ติแฟกต์แพ็กเกจ | งาน: Prepare release package artifact |
| workflow เบื้องหลัง: ไม่มี | |
| การทดสอบ: ตรวจสอบทูเพิลแพ็กเกจแบบเปลี่ยนแปลงไม่ได้ของการรันแบบครอบคลุม หรือแพ็ก tarball ผู้สมัครหนึ่งไฟล์สำหรับการส่ง Release Checks โดยตรง/แบบเจาะจง จากนั้นเปิดให้การตรวจสอบขั้นถัดไปที่เกี่ยวข้องกับแพ็กเกจใช้งาน | |
| การรันซ้ำ: กลุ่มแพ็กเกจ, ข้ามระบบปฏิบัติการ หรือสด/E2E ที่ได้รับผลกระทบ | |
| การทดสอบเบื้องต้นสำหรับการติดตั้ง | งาน: Run install smoke |
workflow เบื้องหลัง: Install Smoke |
|
| การทดสอบ: เส้นทางการติดตั้งเต็มรูปแบบพร้อมการนำอิมเมจทดสอบเบื้องต้นจาก Dockerfile รากกลับมาใช้ใหม่, การติดตั้งแพ็กเกจ QR, การทดสอบเบื้องต้น Docker ของรากและ Gateway, การทดสอบ Docker ของตัวติดตั้ง และการทดสอบเบื้องต้นของผู้ให้บริการอิมเมจสำหรับการติดตั้ง Bun แบบส่วนกลาง | |
การรันซ้ำ: rerun_group=install-smoke |
|
| ข้ามระบบปฏิบัติการ | งาน: cross_os_release_checks |
workflow เบื้องหลัง: OpenClaw Cross-OS Release Checks (Reusable) |
|
| การทดสอบ: เลนการติดตั้งใหม่และอัปเกรดบน Linux, Windows และ macOS สำหรับผู้ให้บริการและโหมดที่เลือก โดยใช้ tarball ผู้สมัครพร้อมแพ็กเกจฐานอ้างอิง | |
การรันซ้ำ: rerun_group=cross-os |
|
| E2E ของรีโพซิทอรีและแบบสด | งาน: Run repo/live E2E validation |
workflow เบื้องหลัง: OpenClaw Live And E2E Checks (Reusable) |
|
การทดสอบ: E2E ของรีโพซิทอรี, แคชสด, การสตรีมผ่าน websocket ของ OpenAI, ชาร์ดผู้ให้บริการสดแบบเนทีฟและ 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 |
workflow เบื้องหลัง: 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 |
workflow เบื้องหลัง: Package Acceptance |
|
การทดสอบ: ฟิกซ์เจอร์แพ็กเกจ Plugin แบบออฟไลน์, การอัปเดต Plugin, E2E แพ็กเกจ Telegram ที่ใช้ OpenAI จำลองซึ่งเป็นมาตรฐาน และการตรวจสอบการคงอยู่หลังการอัปเกรดเวอร์ชันที่เผยแพร่โดยใช้ tarball เดียวกัน การตรวจสอบรีลีสแบบบล็อกใช้เวอร์ชันฐานอ้างอิงล่าสุดที่เผยแพร่เป็นค่าเริ่มต้น ส่วนการตรวจสอบแบบ soak (run_release_soak=true) จะขยายไปยังรีลีส npm เสถียร 4 รายการล่าสุดรวมกับเวอร์ชันย้อนหลังที่ปักหมุดไว้ 3 เวอร์ชัน (2026.4.23, 2026.5.2, 2026.4.15) และรันกับฟิกซ์เจอร์การอัปเกรดของปัญหาที่มีการรายงาน |
|
การรันซ้ำ: rerun_group=package |
|
| บัตรคะแนนวุฒิภาวะ | งาน: Render maturity scorecard release docs |
workflow เบื้องหลัง: 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 |
| workflow เบื้องหลัง: งานโดยตรง | |
| การทดสอบ: ชุดความเท่าเทียมแบบเอเจนต์ของผู้สมัครและฐานอ้างอิง ตามด้วยรายงานความเท่าเทียม | |
การรันซ้ำ: rerun_group=qa-parity หรือ rerun_group=qa |
|
| ความเท่าเทียมของรันไทม์ QA | งาน: Run QA Lab runtime parity lane |
| workflow เบื้องหลัง: งานโดยตรง | |
การทดสอบ: เลนความเท่าเทียมแบบเอเจนต์ของคู่รันไทม์ openclaw/codex (pnpm openclaw qa suite --runtime-pair openclaw,codex) ซึ่งรวมระดับมาตรฐาน และเมื่อใช้ run_release_soak=true จะรวมระดับ soak ด้วย คำแนะนำ: ความล้มเหลวแต่ละรายการจะไม่บล็อกตัวตรวจสอบการตรวจสอบรีลีส |
|
การรันซ้ำ: rerun_group=qa-parity หรือ rerun_group=qa |
|
| ความครอบคลุมเครื่องมือรันไทม์ QA | งาน: Enforce QA Lab runtime tool coverage |
| workflow เบื้องหลัง: งานโดยตรง | |
การทดสอบ: ความคลาดเคลื่อนของเครื่องมือแบบไดนามิกระหว่าง openclaw และ codex ในระดับความเท่าเทียมของรันไทม์มาตรฐาน (pnpm openclaw qa coverage --tools) โดยใช้ผลลัพธ์จากเลนความเท่าเทียมของรันไทม์ QA การบล็อก: งานนี้ไม่สามารถเปลี่ยนเป็นเชิงคำแนะนำได้ |
|
การรันซ้ำ: rerun_group=qa-parity หรือ rerun_group=qa |
|
| Matrix สดของ QA | งาน: Run QA Live Matrix profile |
workflow เบื้องหลัง: workflow ที่ใช้ซ้ำได้ QA-Lab - All Lanes |
|
การทดสอบ: สถานการณ์ YAML ที่พิสูจน์ความเท่าเทียมแล้วผ่านอะแดปเตอร์ Matrix สดที่ใช้ร่วมกันในสภาพแวดล้อม qa-live-shared |
|
การรันซ้ำ: rerun_group=qa-live หรือ rerun_group=qa; ใช้ live_suite_filter=qa-live-matrix สำหรับการรัน Matrix ซ้ำแบบเจาะจง |
|
| Telegram สดของ QA | งาน: Run QA Lab live Telegram lane |
workflow เบื้องหลัง: การส่ง OpenClaw Release Telegram QA ที่เชื่อถือได้ |
|
| การทดสอบ: QA ของ Telegram แบบสดพร้อมการเช่าข้อมูลประจำตัว Convex CI | |
การรันซ้ำ: rerun_group=qa-live หรือ rerun_group=qa |
|
| Discord สดของ QA | งาน: Run QA Lab live Discord lane |
| workflow เบื้องหลัง: งานเชิงคำแนะนำโดยตรง | |
การทดสอบ: QA ของ Discord แบบสดพร้อมการเช่าข้อมูลประจำตัว Convex CI เมื่อเปิดใช้ OPENCLAW_RELEASE_QA_DISCORD_LIVE_CI_ENABLED |
|
การรันซ้ำ: rerun_group=qa-live พร้อม live_suite_filter=qa-live-discord |
|
| WhatsApp สดของ QA | งาน: Run QA Lab live WhatsApp lane |
| workflow เบื้องหลัง: งานเชิงคำแนะนำโดยตรง | |
การทดสอบ: QA ของ WhatsApp แบบสดพร้อมการเช่าข้อมูลประจำตัว Convex CI เมื่อเปิดใช้ OPENCLAW_RELEASE_QA_WHATSAPP_LIVE_CI_ENABLED |
|
การรันซ้ำ: rerun_group=qa-live พร้อม live_suite_filter=qa-live-whatsapp |
|
| Slack สดของ QA | งาน: Run QA Lab live Slack lane |
| workflow เบื้องหลัง: งานเชิงคำแนะนำโดยตรง | |
การทดสอบ: QA ของ Slack แบบสดพร้อมการเช่าข้อมูลประจำตัว Convex CI เมื่อเปิดใช้ OPENCLAW_RELEASE_QA_SLACK_LIVE_CI_ENABLED |
|
การรันซ้ำ: rerun_group=qa-live พร้อม live_suite_filter=qa-live-slack |
|
| ตัวตรวจสอบรีลีส | งาน: Verify release checks |
| workflow เบื้องหลัง: ไม่มี | |
| การทดสอบ: งานตรวจสอบรีลีสที่จำเป็นสำหรับกลุ่มการรันซ้ำที่เลือก | |
| การรันซ้ำ: รันซ้ำหลังจากงานลูกแบบเจาะจงผ่านแล้ว |
ส่วนย่อยของเส้นทางรีลีส 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]> แบบเจาะจงในเวิร์กโฟลว์ live/E2E ที่นำกลับมาใช้ซ้ำได้ เมื่อ
มีเพียงเลน Docker เดียวที่ล้มเหลว อาร์ติแฟกต์ของรีลีสมีคำสั่งรันซ้ำแยกตามเลน
พร้อมอินพุตสำหรับนำอาร์ติแฟกต์แพ็กเกจและอิมเมจกลับมาใช้ซ้ำเมื่อมีให้ใช้งาน
โปรไฟล์รีลีส
release_profile ควบคุมขอบเขตของการทดสอบแบบสด/ผู้ให้บริการภายในการตรวจสอบรีลีสเป็นหลัก
โดยไม่ได้ตัด CI แบบเต็มตามปกติ, Plugin Prerelease, การทดสอบควันการติดตั้ง, การยอมรับแพ็กเกจ
หรือ QA Lab ออก โปรไฟล์ stable และ full จะเรียกใช้ E2E ของรีโพ/แบบสดอย่างครอบคลุม
และครอบคลุมการทดสอบระยะยาวของเส้นทางรีลีส Docker เสมอ โปรไฟล์ beta สามารถเลือกเข้าร่วมด้วย
run_release_soak=true การยอมรับแพ็กเกจจัดเตรียม E2E ของ Telegram สำหรับแพ็กเกจที่เป็นมาตรฐาน
ให้กับตัวเลือก full ทุกตัว ดังนั้นเวิร์กโฟลว์รวมจึงไม่เรียกตัวสำรวจแบบสดนั้นซ้ำ
| โปรไฟล์ | วัตถุประสงค์การใช้งาน | ขอบเขตแบบสด/ผู้ให้บริการที่รวมไว้ |
|---|---|---|
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 Prerelease |
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 เมื่อชุดทดสอบแบบสดหนึ่งชุดล้มเหลว
รหัสตัวกรองที่ใช้ได้กำหนดไว้ในเวิร์กโฟลว์ 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
สำหรับการรันซ้ำการขนส่ง QA แบบเจาะจง ให้ตั้งค่า rerun_group=qa-live และใช้
ตัวเลือกมาตรฐาน qa-live-matrix, qa-live-telegram, qa-live-discord,
qa-live-whatsapp หรือ qa-live-slack
แฮนเดิล live-gateway-advisory-docker เป็นแฮนเดิลรวมสำหรับรันซ้ำชาร์ดผู้ให้บริการ
ทั้งสามชาร์ด จึงยังคงกระจายงานไปยังงาน Gateway เชิงแนะนำใน Docker ทั้งหมด
ใช้ cross_os_suite_filter ร่วมกับ rerun_group=cross-os เมื่อเลนข้ามระบบปฏิบัติการหนึ่งเลน
ล้มเหลว ตัวกรองรองรับรหัสระบบปฏิบัติการ รหัสชุดทดสอบ หรือคู่ระบบปฏิบัติการ/ชุดทดสอบ เช่น
windows/packaged-upgrade, windows หรือ packaged-fresh สรุปผลข้ามระบบปฏิบัติการ
มีระยะเวลาแยกตามเฟสสำหรับเลนอัปเกรดแพ็กเกจ และคำสั่งที่ทำงานเป็นเวลานาน
จะพิมพ์บรรทัด Heartbeat เพื่อให้มองเห็นการอัปเดตที่ค้างก่อนงานหมดเวลา
ความล้มเหลวของการตรวจสอบรีลีส QA จะขัดขวางการตรวจสอบรีลีสตามปกติเฉพาะ
เลนที่เลือกไว้สำหรับ Matrix, Telegram และความครอบคลุมเครื่องมือรันไทม์ QA เท่านั้น ความสอดคล้องของ QA, ความสอดคล้องของรันไทม์
และเลนแบบสดของ Discord, WhatsApp และ Slack ที่มีการควบคุมเป็นเพียงเชิงแนะนำ และ
เผยแพร่อาร์ติแฟกต์สถานะโดยไม่ขัดขวางตัวตรวจสอบรีลีส การรัน 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 ไว้เป็นดัชนีระดับรีลีส โดยเชื่อมโยง
รหัสการรันของเวิร์กโฟลว์ลูกและมีตารางงานที่ช้าที่สุด สำหรับความล้มเหลว ให้ตรวจสอบเวิร์กโฟลว์ลูก
ก่อน แล้วจึงรันแฮนเดิลที่ตรงกันและเล็กที่สุดด้านบนซ้ำ
บันทึกทั้ง Code SHA และ Release SHA, นโยบายการนำกลับมาใช้ซ้ำและชุดเส้นทางที่เปลี่ยนแปลง, การรันแม่ของ Code SHA ที่ผ่าน และการรันแม่ของ Release SHA แบบเบา
อาร์ติแฟกต์ที่มีประโยชน์:
release-package-under-testจากOpenClaw Release Checks- อาร์ติแฟกต์เส้นทางรีลีส Docker ภายใต้
.artifacts/docker-tests/ - การยอมรับแพ็กเกจ
package-under-testและอาร์ติแฟกต์การยอมรับ Docker - อาร์ติแฟกต์การตรวจสอบรีลีสข้ามระบบปฏิบัติการสำหรับแต่ละระบบปฏิบัติการและชุดทดสอบ
- อาร์ติแฟกต์ความสอดคล้องของ QA, ความสอดคล้องของรันไทม์ และ Matrix, Telegram, Discord, WhatsApp หรือ Slack ที่เลือกไว้
ไฟล์เวิร์กโฟลว์
.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
