Release and CI

นโยบายการเผยแพร่

ปัจจุบัน OpenClaw มีช่องทางอัปเดตที่ผู้ใช้มองเห็นสามช่องทาง:

stable: ช่องทางรีลีสที่โปรโมตแล้วซึ่งมีอยู่เดิม โดยยังคงชี้ผ่าน npm latest จนกว่าไมล์สโตนการแยก CLI/ช่องทางจะเสร็จสมบูรณ์
beta: แท็กก่อนรีลีสที่เผยแพร่ไปยัง npm beta
dev: ปลายทางที่เคลื่อนไหวตาม main

นอกจากนี้ ผู้ดำเนินการรีลีสสามารถเผยแพร่แพ็กเกจหลักของเดือนก่อนหน้าที่เสร็จสมบูรณ์ไปยัง npm extended-stable โดยเริ่มที่แพตช์ 33 ส่วนสายรีลีสสมบูรณ์ปกติของเดือนปัจจุบันยังคงอยู่บน npm latest การแยกการเผยแพร่ฝั่งผู้ดำเนินการนี้ไม่ได้เปลี่ยนการเลือกช่องทางอัปเดตของ CLI ด้วยตัวมันเอง

บิลด์อัลฟาของ Tideclaw เป็นสายก่อนรีลีสภายในที่แยกต่างหาก (npm dist-tag alpha) ซึ่งอธิบายไว้ใน อินพุตเวิร์กโฟลว์ NPM และ กล่องทดสอบรีลีส

การตั้งชื่อเวอร์ชัน

เวอร์ชันรีลีส extended-stable รายเดือนบน npm: YYYY.M.PATCH โดย PATCH >= 33 และแท็ก git คือ vYYYY.M.PATCH
เวอร์ชันรีลีสสมบูรณ์รายวัน/ปกติ: YYYY.M.PATCH โดย PATCH < 33 และแท็ก git คือ vYYYY.M.PATCH
เวอร์ชันรีลีสแก้ไขสำรองปกติ: YYYY.M.PATCH-N และแท็ก git คือ vYYYY.M.PATCH-N
เวอร์ชันก่อนรีลีสเบตา: YYYY.M.PATCH-beta.N และแท็ก git คือ vYYYY.M.PATCH-beta.N
เวอร์ชันก่อนรีลีสอัลฟา: YYYY.M.PATCH-alpha.N และแท็ก git คือ vYYYY.M.PATCH-alpha.N
ห้ามเติมเลขศูนย์นำหน้าเดือนหรือแพตช์
PATCH คือหมายเลขลำดับสายรีลีสประจำเดือน ไม่ใช่วันตามปฏิทิน รีลีสสมบูรณ์ปกติและรีลีสเบตาจะเลื่อนสายปัจจุบันไปข้างหน้า ส่วนแท็กที่เป็นอัลฟาเท่านั้นจะไม่ใช้หรือเลื่อนหมายเลขแพตช์ของเบตา/ปกติ ดังนั้นให้ละเว้นแท็กเดิมที่เป็นอัลฟาเท่านั้นและมีหมายเลขแพตช์สูงกว่าเมื่อเลือกสายเบตาหรือสายปกติ
บิลด์อัลฟา/รายคืนใช้สายแพตช์ถัดไปที่ยังไม่รีลีส และเพิ่มเฉพาะ alpha.N สำหรับบิลด์ซ้ำ เมื่อแพตช์นั้นมีเบตาแล้ว บิลด์อัลฟาใหม่จะย้ายไปยังแพตช์ถัดไป
เวอร์ชัน npm เปลี่ยนแปลงไม่ได้: ห้ามลบ เผยแพร่ซ้ำ หรือนำแท็กที่เผยแพร่แล้วกลับมาใช้ใหม่ ให้สร้างหมายเลขก่อนรีลีสถัดไปหรือแพตช์ประจำเดือนถัดไปแทน
latest ยังคงติดตามสาย npm ปกติ/รายวันของเดือนปัจจุบัน ส่วน beta คือเป้าหมายการติดตั้งเบตาปัจจุบัน
extended-stable หมายถึงแพ็กเกจ npm ของเดือนก่อนหน้าที่ยังได้รับการสนับสนุน โดยเริ่มที่แพตช์ 33; แพตช์ 34 และหลังจากนั้นเป็นรีลีสบำรุงรักษาบนสายรายเดือนนั้น
รีลีสสมบูรณ์ปกติและรีลีสแก้ไขปกติจะเผยแพร่ไปยัง npm beta ตามค่าเริ่มต้น ผู้ดำเนินการรีลีสสามารถกำหนดเป้าหมายเป็น latest อย่างชัดเจน หรือโปรโมตบิลด์เบตาที่ผ่านการตรวจสอบแล้วในภายหลัง
เส้นทาง extended-stable รายเดือนโดยเฉพาะจะเผยแพร่แพ็กเกจหลักบน npm และ Plugin ทางการทุกรายการที่เผยแพร่บน npm ได้ด้วยเวอร์ชันเดียวกันทุกประการ เส้นทางนี้ไม่เผยแพร่ Plugin ไปยัง ClawHub และไม่เผยแพร่อาร์ติแฟกต์ macOS หรือ Windows, GitHub Release, dist-tag ของรีโพซิทอรีส่วนตัว, อิมเมจ Docker, อาร์ติแฟกต์อุปกรณ์เคลื่อนที่ หรือไฟล์ดาวน์โหลดจากเว็บไซต์
รีลีสสมบูรณ์ปกติทุกครั้งจะเผยแพร่แพ็กเกจ npm, แอป macOS, Android APK แบบสแตนด์อโลนที่ลงนามแล้ว และตัวติดตั้ง Windows Hub ที่ลงนามแล้วพร้อมกัน โดยปกติรีลีสเบตาจะตรวจสอบและเผยแพร่เส้นทาง npm/แพ็กเกจก่อน ส่วนการบิลด์/ลงนาม/รับรองโดยโนทารี/โปรโมตแอปเนทีฟจะสงวนไว้สำหรับรีลีสสมบูรณ์ปกติ เว้นแต่มีการร้องขออย่างชัดเจน

รอบการรีลีส

รีลีสจะดำเนินตามแนวทางเบตาก่อน ส่วน stable จะตามมาหลังจากเบตาล่าสุดผ่านการตรวจสอบแล้วเท่านั้น
โดยปกติผู้ดูแลจะสร้างรีลีสจากสาขา release/YYYY.M.PATCH ที่สร้างจาก main ปัจจุบัน เพื่อไม่ให้การตรวจสอบและการแก้ไขรีลีสขัดขวางการพัฒนาใหม่บน main
หากมีการพุชหรือเผยแพร่แท็กเบตาแล้วและจำเป็นต้องแก้ไข ผู้ดูแลจะสร้างแท็ก -beta.N ถัดไปแทนการลบหรือสร้างแท็กเดิมใหม่
ขั้นตอนรีลีสโดยละเอียด การอนุมัติ ข้อมูลรับรอง และบันทึกการกู้คืนจำกัดไว้สำหรับผู้ดูแลเท่านั้น

การเผยแพร่ extended-stable รายเดือนเฉพาะ npm

นี่เป็นข้อยกเว้นเฉพาะจากขั้นตอนรีลีสปกติด้านล่าง สำหรับเดือน YYYY.M ที่เสร็จสมบูรณ์แล้ว ให้สร้าง extended-stable/YYYY.M.33 และเผยแพร่ vYYYY.M.33 รวมถึงแพตช์บำรุงรักษาหลังจากนั้นจากสาขาเดียวกัน แท็กรีลีส ปลายสาขา เช็กเอาต์ เวอร์ชันแพ็กเกจ การตรวจสอบล่วงหน้าของ npm และการรันการตรวจสอบรีลีสเต็มรูปแบบต้องระบุคอมมิตเดียวกันทั้งหมด main ที่ได้รับการปกป้องต้องมีเวอร์ชันสมบูรณ์ของเดือนตามปฏิทินที่ใหม่กว่าอย่างเคร่งครัดและมีแพตช์ต่ำกว่า 33 อยู่แล้ว ส่วนแพตช์บำรุงรักษายังคงมีสิทธิ์หลังจาก main เลื่อนไปข้างหน้ามากกว่าหนึ่งเดือน

บนสาขา extended-stable ที่ตรงกันทุกประการ ให้เพิ่มเวอร์ชันแพ็กเกจรากเป็น YYYY.M.P รัน pnpm release:prep และตรวจสอบว่าแพ็กเกจส่วนขยายทุกรายการที่เผยแพร่ได้มีเวอร์ชันเดียวกัน คอมมิตและพุชการเปลี่ยนแปลงที่สร้างขึ้นทั้งหมด สร้างและพุชแท็ก vYYYY.M.P ที่เปลี่ยนแปลงไม่ได้ ณ คอมมิตนั้น และบันทึก SHA แบบเต็มที่ได้ เวิร์กโฟลว์จะใช้ต้นไม้ที่เตรียมไว้นี้ โดยจะไม่เพิ่มหรือซิงโครไนซ์เวอร์ชันให้คุณ

รันการตรวจสอบล่วงหน้าของ npm และการตรวจสอบรีลีสเต็มรูปแบบจากปลายสาขาที่เตรียมไว้นั้นโดยตรง จากนั้นบันทึก ID ของการรันทั้งสองและหมายเลขครั้งที่รันการตรวจสอบรีลีสเต็มรูปแบบที่สำเร็จ:

bash

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=true \  -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

release_profile=stable คือโปรไฟล์ระดับความลึกของการตรวจสอบที่มีอยู่เดิม โดยแยกจาก dist-tag extended-stable ของ npm และจงใจคงไว้โดยไม่เปลี่ยนแปลง

หลังจากการรันทั้งสองสำเร็จ ให้เผยแพร่ Plugin ทางการทุกรายการที่เผยแพร่บน npm ได้จากปลายสาขาเดียวกันทุกประการ แพตช์ P ต้องเป็น 33 ขึ้นไป ส่ง SHA รีลีสแบบเต็มเป็น ref รอให้เมทริกซ์ทั้งหมดและการอ่านค่ากลับจากรีจิสทรีเสร็จสิ้น จากนั้นบันทึก ID ของการรัน Plugin NPM Release ที่สำเร็จ:

bash

RELEASE_SHA="$(git rev-parse HEAD)"gh workflow run plugin-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f publish_scope=all-publishable \  -f ref="$RELEASE_SHA" \  -f npm_dist_tag=extended-stable

เวิร์กโฟลว์ใช้รายการแพ็กเกจ all-publishable ที่เตรียมไว้ตามปกติ รวมถึงแพ็กเกจที่ซอร์สไม่ได้เปลี่ยนแปลง โดยจะตรวจสอบทุกแพ็กเกจที่ตรงกันทุกประการและทุกแท็ก extended-stable ของ Plugin ก่อนสำเร็จ หากการรันบางส่วนล้มเหลว ให้รันคำสั่งเดิมซ้ำ: แพ็กเกจที่เผยแพร่แล้วจะถูกนำกลับมาใช้ แท็ก Plugin ที่ขาดหายหรือล้าสมัยจะได้รับการปรับให้ตรงกันภายใต้สภาพแวดล้อมรีลีส npm และการอ่านค่ากลับขั้นสุดท้ายจะยังคงครอบคลุมชุดแพ็กเกจทั้งหมด

หลังจากเวิร์กโฟลว์ Plugin สำเร็จและสภาพแวดล้อมรีลีส npm พร้อมแล้ว ให้เผยแพร่ tarball หลักจากการตรวจสอบล่วงหน้าที่ตรงกันทุกประการ การเผยแพร่ส่วนหลักจะตรวจสอบว่าการรัน Plugin ที่อ้างอิงมีสถานะ completed/success บนสาขามาตรฐานเดียวกันและมี SHA ซอร์สตรงกันทุกประการ:

bash

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=false \  -f npm_dist_tag=extended-stable \  -f preflight_run_id=<npm-preflight-run-id> \  -f full_release_validation_run_id=<full-validation-run-id> \  -f full_release_validation_run_attempt=<full-validation-run-attempt> \  -f plugin_npm_run_id=<plugin-npm-run-id>

สำหรับฟอร์กหรือการซ้อมที่ไม่ใช่โปรดักชันซึ่งตั้งใจให้ไม่สามารถปฏิบัติตามนโยบาย .33 รายเดือนหรือนโยบายเดือนของ main ที่ได้รับการปกป้องได้ ให้เพิ่ม -f bypass_extended_stable_guard=true ทั้งในการสั่งรันการตรวจสอบล่วงหน้าและการเผยแพร่ npm ค่าเริ่มต้นคือ false การข้ามนี้ยอมรับเฉพาะเมื่อใช้ npm_dist_tag=extended-stable และจะถูกบันทึกไว้ในสรุปเวิร์กโฟลว์ โดยจะไม่ข้ามการอ้างอิงเวิร์กโฟลว์มาตรฐาน extended-stable/YYYY.M.33, ความเท่ากันของปลายสาขา/แท็ก/เช็กเอาต์, ไวยากรณ์แท็กสมบูรณ์, ความเท่ากันของเวอร์ชันแพ็กเกจ/แท็ก, ตัวตนของการรันและแมนิเฟสต์ที่อ้างอิง, ที่มาของ tarball, การอนุมัติสภาพแวดล้อม, การอ่านค่ากลับจากรีจิสทรี หรือหลักฐานการซ่อมแซมตัวเลือก

เวิร์กโฟลว์การเผยแพร่จะตรวจสอบตัวตนของการตรวจสอบล่วงหน้า การตรวจสอบ และการรัน Plugin ที่อ้างอิง ค่าไดเจสต์ของ tarball ที่เตรียมไว้ และตัวเลือกรีจิสทรีหลัก หลังจากเวิร์กโฟลว์สำเร็จ ให้ยืนยันผลอย่างเป็นอิสระ:

bash

npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

ทั้งสองคำสั่งต้องส่งคืน YYYY.M.P หากการเผยแพร่สำเร็จแต่การอ่านค่าตัวเลือกล้มเหลว ห้ามเผยแพร่เวอร์ชันแพ็กเกจที่เปลี่ยนแปลงไม่ได้ซ้ำ ให้ใช้คำสั่งซ่อมแซมเพียงคำสั่งเดียว npm dist-tag add openclaw@YYYY.M.P extended-stable ที่พิมพ์ไว้ในสรุปซึ่งทำงานเสมอของเวิร์กโฟลว์ที่ล้มเหลว จากนั้นทำการอ่านค่ากลับแบบอิสระทั้งสองรายการซ้ำ การย้อนกลับไปยังตัวเลือกก่อนหน้าเป็นการตัดสินใจแยกต่างหากของผู้ดำเนินการ ไม่ใช่เส้นทางซ่อมแซมการอ่านค่ากลับ

เอกสารการสนับสนุนสาธารณะกำหนดให้ Slack, Discord และ Codex เป็นพื้นผิว Plugin ของ extended-stable ที่ครอบคลุมในช่วงแรก รายการดังกล่าวเป็นถ้อยแถลงด้านการสนับสนุน ไม่ใช่รายการอนุญาตในโค้ดรีลีส: Plugin ทางการทุกรายการที่เผยแพร่บน npm ได้จะใช้เส้นทางการเผยแพร่เวอร์ชันเดียวกันทุกประการ

รายการตรวจสอบปกติด้านล่างยังคงรับผิดชอบการเผยแพร่ beta, latest, GitHub Release, Plugin, macOS, Windows และแพลตฟอร์มอื่น ๆ ห้ามรันขั้นตอนเหล่านั้นสำหรับเส้นทาง extended-stable เฉพาะ npm นี้

รายการตรวจสอบสำหรับผู้ดำเนินการรีลีสปกติ

รายการตรวจสอบนี้แสดงรูปแบบสาธารณะของกระบวนการรีลีส ข้อมูลรับรองส่วนตัว การลงนาม การรับรองโดยโนทารี การกู้คืน dist-tag และรายละเอียดการย้อนกลับฉุกเฉินจะอยู่ในคู่มือการรีลีสสำหรับผู้ดูแลเท่านั้น

เริ่มจาก main ปัจจุบัน: ดึงการเปลี่ยนแปลงล่าสุด ยืนยันว่าได้พุชคอมมิตเป้าหมายแล้ว และยืนยันว่า CI ของ main ผ่านเพียงพอสำหรับการสร้างสาขาจากจุดนั้น
สร้างส่วนบนสุดของ CHANGELOG.md จาก PR ที่ผสานแล้วและคอมมิตโดยตรงทั้งหมดนับจากแท็กรุ่นล่าสุดที่เข้าถึงได้ เขียนรายการโดยคำนึงถึงผู้ใช้ ขจัดรายการ PR/คอมมิตโดยตรงที่ซ้ำซ้อนกัน คอมมิต พุช และรีเบส/ดึงอีกครั้งก่อนสร้างสาขา เมื่อแท็กที่เผยแพร่แล้วซึ่งแยกสายออกไป หรือการพอร์ตไปข้างหน้าในภายหลัง เชื่อมโยง PR ที่เผยแพร่แล้วเข้ามาใหม่ ให้ส่งแท็กนั้นอย่างชัดเจนผ่าน --shipped-ref; ตัวตรวจสอบจะใช้แถว PR ที่ระบุชัดเจนจากระเบียนการมีส่วนร่วมที่สมบูรณ์ในส่วนที่มีหมายเลขของสแนปช็อตแท็ก ไม่สนใจ Unreleased และบันทึกรายการ PR ที่ถูกยกเว้นอย่างถูกต้องพร้อมจำนวน
ตรวจสอบระเบียนความเข้ากันได้ของรุ่นใน src/plugins/compat/registry.ts และ src/commands/doctor/shared/deprecation-compat.ts ลบความเข้ากันได้ที่หมดอายุเฉพาะเมื่อเส้นทางการอัปเกรดยังคงครอบคลุมอยู่ หรือบันทึกเหตุผลที่ตั้งใจคงไว้
สร้าง release/YYYY.M.PATCH จาก main ปัจจุบัน อย่าดำเนินงานออกรุ่นตามปกติโดยตรงบน main
เพิ่มหมายเลขเวอร์ชันในทุกตำแหน่งที่แท็กกำหนด จากนั้นเรียกใช้ pnpm release:prep คำสั่งนี้จะรีเฟรชเวอร์ชัน Plugin, npm shrinkwrap, รายการ Plugin, สคีมาคอนฟิกพื้นฐาน, เมทาดาทาคอนฟิกช่องทางที่รวมมาให้, ค่าฐานของเอกสารคอนฟิก, การส่งออกของ Plugin SDK และค่าฐาน API ของ Plugin SDK ตามลำดับ คอมมิตความคลาดเคลื่อนที่สร้างขึ้นทั้งหมดก่อนติดแท็ก จากนั้นเรียกใช้การตรวจสอบเบื้องต้นแบบกำหนดผลแน่นอนภายในเครื่อง: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build และ pnpm release:check
เรียกใช้ OpenClaw NPM Release โดยกำหนด preflight_only=true ก่อนมีแท็ก สามารถใช้ SHA แบบเต็ม 40 อักขระของสาขารุ่นสำหรับการตรวจสอบเบื้องต้นเพื่อการตรวจสอบความถูกต้องเท่านั้นได้ การตรวจสอบเบื้องต้นจะสร้างหลักฐานการออกรุ่นของการขึ้นต่อกันสำหรับกราฟการขึ้นต่อกันที่เช็กเอาต์อย่างถูกต้อง และจัดเก็บไว้ในอาร์ติแฟกต์การตรวจสอบเบื้องต้นของ npm บันทึก preflight_run_id ที่สำเร็จไว้
เริ่มการทดสอบก่อนออกรุ่นทั้งหมดด้วย Full Release Validation สำหรับสาขารุ่น แท็ก หรือ SHA แบบเต็มของคอมมิต นี่คือจุดเริ่มต้นแบบสั่งด้วยตนเองเพียงจุดเดียวสำหรับกล่องทดสอบการออกรุ่นขนาดใหญ่ทั้งสี่รายการ ได้แก่ Vitest, Docker, QA Lab และ Package บันทึก full_release_validation_run_id และ full_release_validation_run_attempt ที่ถูกต้องไว้ ทั้งสองค่าเป็นอินพุตที่จำเป็นสำหรับ OpenClaw NPM Release และ OpenClaw Release Publish
หากการตรวจสอบความถูกต้องล้มเหลว ให้แก้ไขบนสาขารุ่นและเรียกใช้ซ้ำเฉพาะไฟล์ เลน งานเวิร์กโฟลว์ โปรไฟล์แพ็กเกจ ผู้ให้บริการ หรือรายการอนุญาตของโมเดลที่ล้มเหลวในขอบเขตเล็กที่สุดซึ่งพิสูจน์การแก้ไขได้ เรียกใช้ชุดครอบคลุมทั้งหมดซ้ำเฉพาะเมื่อพื้นผิวที่เปลี่ยนแปลงทำให้หลักฐานก่อนหน้าไม่เป็นปัจจุบัน
สำหรับรุ่นเบต้าที่ติดแท็ก ให้เรียกใช้ pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N จากสาขา release/YYYY.M.PATCH ที่ตรงกัน สำหรับรุ่นเสถียร ให้ส่งรุ่นซอร์ส Windows ที่จำเป็นด้วย: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z ตัวช่วยใช้ main ที่เชื่อถือได้เป็นซอร์สของเวิร์กโฟลว์ ขณะที่แต่ละเวิร์กโฟลว์กำหนดเป้าหมายไปยังแท็กที่ถูกต้อง ตัวช่วยจะบันทึกจุดตรวจของอัตลักษณ์ผู้สมัครรุ่น/เครื่องมือที่เปลี่ยนแปลงไม่ได้และรหัสการรันที่ส่งไปไว้ใน .artifacts/release-candidate/<tag>/release-candidate-state.json; การเรียกใช้คำสั่งเดิมซ้ำจะดำเนินการต่อจากการรันเดิมเหล่านั้นอย่างถูกต้อง ขณะที่ความคลาดเคลื่อนใด ๆ ของผู้สมัครรุ่น เครื่องมือ โปรไฟล์ หรือตัวเลือกจะทำให้หยุดทำงานโดยปริยาย ก่อนส่งเมทริกซ์การตรวจสอบความถูกต้องทั้งหมด ตัวช่วยจะเรนเดอร์เนื้อหารุ่น GitHub ของแท็กที่ถูกต้องแบบกำหนดผลแน่นอน และปฏิเสธกรณีที่ไม่มีหัวข้อเวอร์ชัน เนื้อหายาวเกินขีดจำกัดและไม่สามารถใช้รูปแบบย่อมาตรฐานได้ หรือที่มาของฐาน/เป้าหมายในระเบียนการมีส่วนร่วมไม่สามารถเข้าถึงได้จากแท็ก นอกจากนี้ยังตรวจสอบเมทาดาทาการยกเว้นค่าฐานที่เผยแพร่แล้วซึ่งระบุไว้อย่างชัดเจนกับระเบียนแท็กสะสมที่อ้างอิง จากนั้นจึงเรียกใช้การตรวจสอบรุ่นที่สร้างขึ้นภายในเครื่อง ส่งหรือยืนยันหลักฐานการตรวจสอบความถูกต้องของรุ่นแบบเต็มและการตรวจสอบเบื้องต้นของ npm เรียกใช้หลักฐานการติดตั้งใหม่/อัปเดตของ Parallels กับ tarball ที่จัดเตรียมไว้อย่างถูกต้องพร้อมหลักฐานแพ็กเกจ Telegram บันทึกแผน npm และ ClawHub ของ Plugin และแสดงคำสั่ง OpenClaw Release Publish ที่ถูกต้องเฉพาะเมื่อชุดหลักฐานผ่านทั้งหมดแล้ว

OpenClaw Release Publish จะส่งแพ็กเกจ Plugin ที่เลือกหรือทั้งหมดที่เผยแพร่ได้ไปยัง npm และส่งชุดเดียวกันไปยัง ClawHub แบบขนาน จากนั้นเลื่อนระดับอาร์ติแฟกต์การตรวจสอบเบื้องต้นของ npm สำหรับ OpenClaw ที่จัดเตรียมไว้ด้วย dist-tag ที่ตรงกันเมื่อการเผยแพร่ Plugin ไปยัง npm สำเร็จ เช็กเอาต์ของรุ่นยังคงเป็นรากของผลิตภัณฑ์/ข้อมูล ขณะที่การวางแผนและการตรวจสอบขั้นสุดท้ายทำงานจากเช็กเอาต์ซอร์สเวิร์กโฟลว์ที่เชื่อถือได้และถูกต้อง เพื่อป้องกันไม่ให้คอมมิตรุ่นเก่าใช้เครื่องมือออกรุ่นที่ล้าสมัยโดยไม่มีการแจ้งเตือน ก่อนเริ่มงานย่อยสำหรับการเผยแพร่ใด ๆ ระบบจะเรนเดอร์และแคชเนื้อหารุ่น GitHub ที่ถูกต้อง เมื่อส่วน CHANGELOG.md ที่ตรงกันและสมบูรณ์มีขนาดไม่เกินขีดจำกัด 125,000 อักขระของ GitHub และเพดานความปลอดภัย 125,000 ไบต์ที่ตรงกันของตัวเรนเดอร์ หน้าดังกล่าวจะมีส่วน ## YYYY.M.PATCH ที่ถูกต้องรวมถึงหัวข้อ เมื่อส่วนต้นทางมีขนาดเกินขีดจำกัด หน้าจะเก็บหมายเหตุบรรณาธิการแบบจัดกลุ่มที่ถูกต้องไว้ และแทนที่ระเบียนการมีส่วนร่วมที่ใหญ่เกินไปด้วยลิงก์คงที่ไปยังระเบียนฉบับเต็มใน CHANGELOG.md ที่ตรึงกับแท็ก โดยจะไม่เผยแพร่ระเบียนที่ไม่สมบูรณ์หรือรายการหัวข้อย่อยที่ถูกตัดทอน เวิร์กโฟลว์จะเลือกเนื้อหาฉบับเต็มหรือฉบับย่อนี้ก่อนเพิ่ม ### Release verification; หากส่วนท้ายของหลักฐานทำให้เกินขีดจำกัด ระบบจะคงเนื้อหามาตรฐานไว้และใช้หลักฐานแนบที่เปลี่ยนแปลงไม่ได้แทน รุ่นเสถียรที่เผยแพร่ไปยัง npm latest จะกลายเป็นรุ่นล่าสุดของ GitHub ขณะที่รุ่นบำรุงรักษาแบบเสถียรซึ่งคงไว้บน npm beta จะถูกสร้างโดยกำหนด GitHub latest=false เวิร์กโฟลว์ยังอัปโหลดหลักฐานการขึ้นต่อกันจากการตรวจสอบเบื้องต้น แมนิเฟสต์การตรวจสอบความถูกต้องแบบเต็ม และหลักฐานการตรวจสอบรีจิสทรีหลังเผยแพร่ไปยังรุ่น GitHub เพื่อรองรับการตอบสนองต่อเหตุขัดข้องหลังออกรุ่น ระบบจะแสดงรหัสการรันของงานย่อยทันที อนุมัติเกตสภาพแวดล้อมการออกรุ่นที่โทเค็นเวิร์กโฟลว์มีสิทธิ์อนุมัติโดยอัตโนมัติ สรุปงานย่อยที่ล้มเหลวพร้อมส่วนท้ายของบันทึก สร้างหน้ารุ่น GitHub แบบฉบับร่างไว้ล่วงหน้า และเลื่อนระดับแอสเซ็ต Windows กับ Android พร้อมกันกับการเผยแพร่ OpenClaw ไปยัง npm ปิดงานหน้ารุ่นและหลักฐานการขึ้นต่อกันเมื่อขั้นตอนเหล่านั้นสำเร็จ รอ ClawHub ทุกครั้งที่กำลังเผยแพร่ OpenClaw ไปยัง npm จากนั้นเรียกใช้ตัวตรวจสอบเบต้าจาก main ที่เชื่อถือได้ และอัปโหลดหลักฐานหลังเผยแพร่สำหรับรุ่น GitHub, แพ็กเกจ npm, แพ็กเกจ Plugin บน npm ที่เลือก, แพ็กเกจ ClawHub ที่เลือก, รหัสการรันของเวิร์กโฟลว์ย่อย และรหัสการรัน NPM Telegram ที่ไม่บังคับ ตัวตรวจสอบการเริ่มต้นระบบของ ClawHub ต้องใช้เส้นทางและ SHA ของเวิร์กโฟลว์จาก main ที่เชื่อถือได้อย่างถูกต้อง จำนวนครั้งการรันของผู้สร้างและการรันปลายทาง SHA ของรุ่น ชุดแพ็กเกจที่ร้องขอ ทูเพิลอาร์ติแฟกต์แพ็กเกจที่เปลี่ยนแปลงไม่ได้ และอาร์ติแฟกต์การอ่านค่ากลับจากรีจิสทรีของการรันปลายทาง โดยจะไม่ยอมรับการรันแบบอ้างอิงรุ่นดั้งเดิมที่สำเร็จ

จากนั้นเรียกใช้การยอมรับแพ็กเกจหลังเผยแพร่กับแพ็กเกจ openclaw@YYYY.M.PATCH-beta.N หรือ openclaw@beta ที่เผยแพร่แล้ว หากรุ่นก่อนเผยแพร่ที่พุชหรือเผยแพร่แล้วจำเป็นต้องแก้ไข ให้สร้างหมายเลขรุ่นก่อนเผยแพร่ถัดไปที่ตรงกัน ห้ามลบหรือเขียนทับรุ่นเดิม
สำหรับรุ่นเสถียร ให้ดำเนินการต่อเฉพาะหลังจากรุ่นเบต้าหรือผู้สมัครรุ่นที่ผ่านการตรวจสอบมีหลักฐานการตรวจสอบความถูกต้องที่จำเป็น การเผยแพร่รุ่นเสถียรไปยัง npm ต้องผ่าน OpenClaw Release Publish เช่นกัน โดยนำอาร์ติแฟกต์การตรวจสอบเบื้องต้นที่สำเร็จกลับมาใช้ผ่าน preflight_run_id ความพร้อมของรุ่นเสถียรสำหรับ macOS ยังต้องมี .zip, .dmg, .dSYM.zip ที่จัดแพ็กเกจแล้ว และ appcast.xml ที่อัปเดตบน main; เวิร์กโฟลว์การเผยแพร่ macOS จะเผยแพร่ appcast ที่ลงนามแล้วไปยัง main สาธารณะโดยอัตโนมัติหลังตรวจสอบแอสเซ็ตรุ่น หรือเปิด/อัปเดต PR ของ appcast หากการป้องกันสาขาขัดขวางการพุชโดยตรง ความพร้อมของ Windows Hub สำหรับรุ่นเสถียรต้องมีแอสเซ็ต OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe และ OpenClawCompanion-SHA256SUMS.txt ที่ลงนามแล้วบนรุ่น GitHub ของ OpenClaw ส่งแท็กรุ่น openclaw/openclaw-windows-node ที่ลงนามแล้วอย่างถูกต้องเป็น windows_node_tag และแผนที่ไดเจสต์ของตัวติดตั้งที่ผู้สมัครรุ่นอนุมัติเป็น windows_node_installer_digests; OpenClaw Release Publish จะคงฉบับร่างของรุ่นไว้ ส่ง Windows Node Release และตรวจสอบแอสเซ็ตทั้งสามรายการก่อนเผยแพร่
หลังเผยแพร่ ให้เรียกใช้ตัวตรวจสอบหลังเผยแพร่ของ npm, Telegram E2E แบบแยกเดี่ยวบน npm ที่เผยแพร่แล้วซึ่งไม่บังคับเมื่อต้องการหลักฐานช่องทางหลังเผยแพร่, การเลื่อนระดับ dist-tag เมื่อจำเป็น ตรวจสอบหน้ารุ่น GitHub ที่สร้างขึ้น เรียกใช้ขั้นตอนประกาศรุ่น จากนั้นดำเนินการ ปิดงาน main สำหรับรุ่นเสถียร ให้เสร็จก่อนประกาศว่าการออกรุ่นเสถียรเสร็จสมบูรณ์

ปิดงาน `main` สำหรับรุ่นเสถียร

การเผยแพร่รุ่นเสถียรจะยังไม่สมบูรณ์จนกว่า main จะมีสถานะของรุ่นที่เผยแพร่จริง

เริ่มจาก main ล่าสุดที่ดึงมาใหม่ ตรวจสอบ release/YYYY.M.PATCH เทียบกับสาขานี้ และพอร์ตการแก้ไขจริงที่ยังไม่มีใน main ไปข้างหน้า อย่าผสานตัวปรับความเข้ากันได้ การทดสอบ หรือการตรวจสอบความถูกต้องที่ใช้เฉพาะรุ่นเข้าสู่ main รุ่นใหม่กว่าโดยไม่พิจารณา
กำหนด main ให้เป็นเวอร์ชันเสถียรที่เผยแพร่แล้ว ไม่ใช่สายรุ่นถัดไปที่คาดการณ์ไว้ เรียกใช้ pnpm release:prep หลังเปลี่ยนเวอร์ชันราก จากนั้นเรียกใช้ pnpm deps:shrinkwrap:generate
ทำให้ส่วน ## YYYY.M.PATCH ของ CHANGELOG.md บน main ตรงกับสาขารุ่นที่ติดแท็กทุกประการ รวมการอัปเดต appcast.xml สำหรับรุ่นเสถียรเมื่อมีการเผยแพร่รุ่น Mac
อย่าเพิ่ม YYYY.M.PATCH+1, เวอร์ชันเบต้า หรือส่วนบันทึกการเปลี่ยนแปลงในอนาคตที่ว่างเปล่าลงใน main จนกว่าผู้ดำเนินการจะเริ่มสายการออกรุ่นนั้นอย่างชัดเจน
เรียกใช้ pnpm release:generated:check, pnpm deps:shrinkwrap:check และ OPENCLAW_TESTBOX=1 pnpm check:changed พุช จากนั้นตรวจสอบว่า origin/main มีเวอร์ชันและบันทึกการเปลี่ยนแปลงที่เผยแพร่แล้วก่อนประกาศว่าการออกรุ่นเสถียรเสร็จสมบูรณ์
รักษาตัวแปรของที่เก็บ RELEASE_ROLLBACK_DRILL_ID และ RELEASE_ROLLBACK_DRILL_DATE ให้เป็นปัจจุบันหลังการฝึกซ้อมย้อนกลับแบบส่วนตัวแต่ละครั้ง

OpenClaw Stable Main Closeout เริ่มจากการพุชไปยัง main ซึ่งมีเวอร์ชัน บันทึกการเปลี่ยนแปลง และ appcast ที่เผยแพร่แล้วหลังการเผยแพร่รุ่นเสถียร ระบบจะอ่านหลักฐานหลังเผยแพร่ที่เปลี่ยนแปลงไม่ได้เพื่อผูกแท็กที่เผยแพร่กับการรัน Full Release Validation และ Publish จากนั้นตรวจสอบสถานะ main สำหรับรุ่นเสถียร รุ่น ระยะเฝ้าระวังภาคบังคับสำหรับรุ่นเสถียร และหลักฐานประสิทธิภาพที่เป็นเงื่อนไขบังคับ ระบบจะแนบแมนิเฟสต์การปิดงานที่เปลี่ยนแปลงไม่ได้และผลรวมตรวจสอบไปยังรุ่น GitHub ทริกเกอร์การพุชอัตโนมัติจะข้ามรุ่นดั้งเดิมที่เก่ากว่าหลักฐานหลังเผยแพร่แบบเปลี่ยนแปลงไม่ได้ และจะไม่ถือว่าการข้ามดังกล่าวเป็นการปิดงานที่เสร็จสมบูรณ์

การปิดงานที่สมบูรณ์ต้องมีทั้งแอสเซ็ตและผลรวมตรวจสอบที่ตรงกัน แมนิเฟสต์ที่ไม่สมบูรณ์จะเล่น SHA ของ main และการฝึกซ้อมย้อนกลับที่บันทึกไว้ซ้ำเพื่อสร้างไบต์ที่เหมือนกัน จากนั้นแนบผลรวมตรวจสอบที่ขาดหายไป คู่ข้อมูลที่ไม่ถูกต้อง หรือผลรวมตรวจสอบที่ไม่มีแมนิเฟสต์ จะยังคงเป็นเงื่อนไขปิดกั้น การรันที่ทริกเกอร์ด้วยการพุชโดยไม่มีตัวแปรที่เก็บสำหรับการฝึกซ้อมย้อนกลับจะข้ามโดยไม่ทำให้การปิดงานเสร็จสมบูรณ์ ระเบียนการฝึกซ้อมที่ไม่มีอยู่หรือเก่ากว่า 90 วันยังคงปิดกั้นการปิดงานแบบสั่งด้วยตนเองที่มีหลักฐานรองรับ คำสั่งกู้คืนแบบส่วนตัวยังคงอยู่ในคู่มือดำเนินงานสำหรับผู้ดูแลเท่านั้น ใช้การส่งงานด้วยตนเองเฉพาะเพื่อซ่อมแซมหรือเล่นซ้ำการปิดงานรุ่นเสถียรที่มีหลักฐานรองรับ

แท็กแก้ไขสำรองแบบดั้งเดิมสามารถนำหลักฐานแพ็กเกจพื้นฐานกลับมาใช้ได้เฉพาะเมื่อแท็กแก้ไขชี้ไปยังคอมมิตซอร์สเดียวกับแท็กรุ่นเสถียรพื้นฐาน รุ่น Android ของแท็กดังกล่าวจะนำ APK ที่ตรวจสอบแล้วของแท็กพื้นฐานกลับมาใช้ และเพิ่มข้อมูลที่มาสำหรับแท็กแก้ไข การแก้ไขที่ใช้ซอร์สต่างกันต้องเผยแพร่และตรวจสอบหลักฐานแพ็กเกจของตนเอง และใช้ versionCode ของ Android ที่สูงกว่า

การตรวจสอบเบื้องต้นก่อนออกรุ่น

เรียกใช้ pnpm check:test-types ก่อนการตรวจสอบเบื้องต้นก่อนเผยแพร่ เพื่อให้ TypeScript สำหรับการทดสอบยังคงได้รับการตรวจครอบคลุมนอกเกต pnpm check ภายในเครื่องที่ทำงานเร็วกว่า
เรียกใช้ pnpm check:architecture ก่อนการตรวจสอบเบื้องต้นก่อนเผยแพร่ เพื่อให้การตรวจสอบวงจรการนำเข้าและขอบเขตสถาปัตยกรรมในวงกว้างผ่านทั้งหมดนอกเกตภายในเครื่องที่ทำงานเร็วกว่า
เรียกใช้ pnpm build && pnpm ui:build ก่อน pnpm release:check เพื่อให้อาร์ติแฟกต์รุ่นเผยแพร่ dist/* ที่คาดไว้และบันเดิลส่วนติดต่อผู้ใช้ควบคุมพร้อมใช้งานสำหรับขั้นตอนตรวจสอบแพ็กเกจ
เรียกใช้ pnpm release:prep หลังเพิ่มเวอร์ชันที่รูทและก่อนสร้างแท็ก คำสั่งนี้เรียกใช้ตัวสร้างรุ่นเผยแพร่แบบกำหนดผลลัพธ์ได้ทุกตัวที่มักคลาดเคลื่อนหลังการเปลี่ยนเวอร์ชัน/การกำหนดค่า/API ได้แก่ เวอร์ชัน Plugin, npm shrinkwrap, บัญชีรายการ Plugin, สคีมาการกำหนดค่าพื้นฐาน, เมทาดาทาการกำหนดค่าช่องทางที่รวมมาให้, ค่าฐานของเอกสารการกำหนดค่า, การส่งออก SDK ของ Plugin และค่าฐาน API ของ SDK ของ Plugin ส่วน pnpm release:check จะเรียกใช้เกตเหล่านั้นซ้ำในโหมดตรวจสอบ (พร้อมการตรวจสอบงบประมาณพื้นผิว SDK ของ Plugin) และรายงานความล้มเหลวจากความคลาดเคลื่อนที่สร้างขึ้นทั้งหมดในรอบเดียว ก่อนเรียกใช้การตรวจสอบการเผยแพร่แพ็กเกจ
การซิงค์เวอร์ชัน Plugin จะอัปเดตแพ็กเกจรันไทม์ @openclaw/ai ที่เผยแพร่ได้ เวอร์ชันแพ็กเกจ Plugin อย่างเป็นทางการ และค่าขั้นต่ำ openclaw.compat.pluginApi ที่มีอยู่ให้ตรงกับเวอร์ชันเผยแพร่ของ OpenClaw โดยค่าเริ่มต้น ให้ถือว่าฟิลด์นี้เป็นค่าขั้นต่ำของ API ของ SDK/รันไทม์ Plugin ไม่ใช่เพียงสำเนาเวอร์ชันแพ็กเกจ สำหรับรุ่นเผยแพร่เฉพาะ Plugin ที่ตั้งใจให้ยังเข้ากันได้กับโฮสต์ OpenClaw รุ่นเก่า ให้คงค่าขั้นต่ำไว้ที่ API ของโฮสต์รุ่นเก่าสุดที่รองรับ และบันทึกเหตุผลของตัวเลือกนี้ไว้ในหลักฐานการเผยแพร่ Plugin
เรียกใช้เวิร์กโฟลว์ Full Release Validation แบบดำเนินการด้วยตนเองก่อนอนุมัติการเผยแพร่ เพื่อเริ่มกล่องทดสอบก่อนเผยแพร่ทั้งหมดจากจุดเริ่มต้นเดียว เวิร์กโฟลว์นี้รับสาขา แท็ก หรือ SHA ของคอมมิตแบบเต็ม จากนั้นส่งงาน CI แบบดำเนินการด้วยตนเอง และส่งงาน OpenClaw Release Checks สำหรับการทดสอบเบื้องต้นของการติดตั้ง การยอมรับแพ็กเกจ การตรวจสอบแพ็กเกจข้ามระบบปฏิบัติการ ความสอดคล้องกับห้องปฏิบัติการ QA, Matrix และเลน Telegram การทำงานแบบเสถียรและแบบเต็มจะรวมการทดสอบสด/E2E อย่างละเอียดและการทดสอบแช่เส้นทางเผยแพร่ผ่าน Docker เสมอ ส่วน run_release_soak=true ยังคงมีไว้สำหรับการทดสอบแช่รุ่นเบตาที่ระบุอย่างชัดเจน การยอมรับแพ็กเกจเป็นแหล่งการทดสอบ E2E ของ Telegram สำหรับแพ็กเกจที่เป็นมาตรฐานระหว่างการตรวจสอบรุ่นผู้สมัคร จึงหลีกเลี่ยงตัวสำรวจแบบสดตัวที่สองซึ่งทำงานพร้อมกัน

ระบุ release_package_spec หลังเผยแพร่รุ่นเบตา เพื่อใช้แพ็กเกจ npm ที่เผยแพร่แล้วซ้ำในการตรวจสอบรุ่นเผยแพร่ การยอมรับแพ็กเกจ และการทดสอบ E2E ของ Telegram สำหรับแพ็กเกจ โดยไม่ต้องสร้าง tarball ของรุ่นเผยแพร่ใหม่ ระบุ npm_telegram_package_spec เฉพาะเมื่อ Telegram ควรใช้แพ็กเกจที่เผยแพร่คนละแพ็กเกจกับการตรวจสอบรุ่นเผยแพร่ส่วนที่เหลือ ระบุ package_acceptance_package_spec เมื่อการยอมรับแพ็กเกจควรใช้แพ็กเกจที่เผยแพร่คนละแพ็กเกจกับข้อกำหนดแพ็กเกจรุ่นเผยแพร่ ระบุ evidence_package_spec เมื่อรายงานหลักฐานรุ่นเผยแพร่ควรพิสูจน์ว่าการตรวจสอบตรงกับแพ็กเกจ npm ที่เผยแพร่แล้ว โดยไม่บังคับให้ทำการทดสอบ E2E ของ Telegram
bash
```
gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
```
เรียกใช้เวิร์กโฟลว์ Package Acceptance แบบดำเนินการด้วยตนเองเมื่อต้องการหลักฐานจากช่องทางเสริมสำหรับแพ็กเกจผู้สมัครระหว่างที่งานเผยแพร่ยังดำเนินต่อไป ใช้ source=npm สำหรับ openclaw@beta, openclaw@latest หรือเวอร์ชันเผยแพร่ที่ระบุแน่นอน ใช้ source=ref เพื่อแพ็กสาขา/แท็ก/SHA package_ref ที่เชื่อถือได้ด้วยชุดควบคุม workflow_ref ปัจจุบัน ใช้ source=url สำหรับ tarball HTTPS สาธารณะที่ต้องระบุ SHA-256 และเป็นไปตามนโยบาย URL สาธารณะที่เข้มงวด ใช้ source=trusted-url สำหรับนโยบายแหล่งที่เชื่อถือได้ซึ่งระบุชื่อ โดยต้องระบุ trusted_source_id และ SHA-256 หรือใช้ source=artifact สำหรับ tarball ที่อัปโหลดโดยการทำงานอื่นของ GitHub Actions

เวิร์กโฟลว์จะแปลงรุ่นผู้สมัครเป็น package-under-test ใช้ตัวจัดกำหนดการเผยแพร่ E2E ของ Docker ซ้ำกับ tarball นั้น และสามารถเรียกใช้ QA ของ Telegram กับ tarball เดียวกันด้วย telegram_mode=mock-openai หรือ telegram_mode=live-frontier เมื่อเลน Docker ที่เลือกมี published-upgrade-survivor อาร์ติแฟกต์แพ็กเกจจะเป็นรุ่นผู้สมัคร และ published_upgrade_survivor_baseline จะเลือกค่าฐานที่เผยแพร่แล้ว update-restart-auth ใช้แพ็กเกจผู้สมัครเป็นทั้ง CLI ที่ติดตั้งและแพ็กเกจภายใต้การทดสอบ เพื่อให้ทดสอบเส้นทางรีสตาร์ตที่มีการจัดการของคำสั่งอัปเดตในรุ่นผู้สมัคร

ตัวอย่าง:
bash
```
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
```
โปรไฟล์ที่ใช้ทั่วไป:
- smoke: เลนการติดตั้ง/ช่องทาง/เอเจนต์ เครือข่าย Gateway และการโหลดการกำหนดค่าใหม่
- package: เลนแพ็กเกจ/อัปเดต/รีสตาร์ต/Plugin ที่ทำงานจากอาร์ติแฟกต์โดยตรง โดยไม่มี OpenWebUI หรือ ClawHub แบบสด
- product: โปรไฟล์แพ็กเกจพร้อมช่องทาง MCP, การล้าง cron/เอเจนต์ย่อย, การค้นหาเว็บของ OpenAI และ OpenWebUI
- full: ส่วนย่อยของเส้นทางเผยแพร่ผ่าน Docker พร้อม OpenWebUI
- custom: การเลือก docker_lanes ที่แน่นอนสำหรับเรียกใช้ซ้ำแบบเจาะจง
เรียกใช้เวิร์กโฟลว์ CI แบบดำเนินการด้วยตนเองโดยตรง เมื่อคุณต้องการเพียงความครอบคลุมของ CI ปกติแบบกำหนดผลลัพธ์ได้สำหรับรุ่นผู้สมัคร การส่งงาน CI ด้วยตนเองจะข้ามการจำกัดขอบเขตตามการเปลี่ยนแปลง และบังคับใช้ชาร์ด Linux Node, ชาร์ด Plugin ที่รวมมาให้, ชาร์ดสัญญา Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, check-*, check-additional-*, การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ที่สร้างแล้ว, การตรวจสอบเอกสาร, Skills ของ Python, Windows, macOS และเลนการแปลส่วนติดต่อผู้ใช้ควบคุม การเรียกใช้ CI แบบดำเนินการด้วยตนเองแยกต่างหากจะเรียกใช้ Android เฉพาะเมื่อส่งงานด้วย include_android=true ส่วน Full Release Validation จะส่งค่าอินพุตนี้ให้กับงาน CI ลูก
bash
```
gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
```
เรียกใช้ pnpm qa:otel:smoke เมื่อตรวจสอบเทเลเมทรีของรุ่นเผยแพร่ คำสั่งนี้ทดสอบห้องปฏิบัติการ QA ผ่านตัวรับ OTLP/HTTP ภายในเครื่อง และตรวจสอบการส่งออกเทรซ เมตริก และบันทึก รวมถึงแอตทริบิวต์เทรซที่มีขอบเขตจำกัดและการปกปิดเนื้อหา/ตัวระบุ โดยไม่ต้องใช้ Opik, Langfuse หรือตัวรวบรวมภายนอกอื่น
เรียกใช้ pnpm qa:otel:collector-smoke เมื่อตรวจสอบความเข้ากันได้กับตัวรวบรวม คำสั่งนี้ส่งออก OTLP จากห้องปฏิบัติการ QA ชุดเดียวกันผ่านคอนเทนเนอร์ Docker ของ OpenTelemetry Collector จริง ก่อนดำเนินการยืนยันกับตัวรับภายในเครื่อง
เรียกใช้ pnpm qa:prometheus:smoke เมื่อตรวจสอบการดึงข้อมูล Prometheus ที่มีการป้องกัน คำสั่งนี้ทดสอบห้องปฏิบัติการ QA ปฏิเสธการดึงข้อมูลที่ไม่ผ่านการยืนยันตัวตน และตรวจสอบว่าตระกูลเมตริกที่สำคัญต่อการเผยแพร่ไม่มีเนื้อหาพรอมต์ ตัวระบุดิบ โทเค็นยืนยันตัวตน และพาธภายในเครื่อง
เรียกใช้ pnpm qa:observability:smoke เพื่อเรียกเลนทดสอบเบื้องต้นของ OpenTelemetry และ Prometheus สำหรับเช็กเอาต์ซอร์สโค้ดต่อเนื่องกัน
เรียกใช้ pnpm release:check ก่อนการเผยแพร่ที่มีแท็กทุกครั้ง
การตรวจสอบเบื้องต้น OpenClaw NPM Release จะสร้างหลักฐานการเผยแพร่ของการขึ้นต่อกันก่อนแพ็ก tarball สำหรับ npm เกตช่องโหว่จากคำแนะนำความปลอดภัยของ npm จะขัดขวางการเผยแพร่หากไม่ผ่าน ส่วนรายงานความเสี่ยงของแมนิเฟสต์แบบส่งผ่าน พื้นผิวความเป็นเจ้าของ/การติดตั้งของการขึ้นต่อกัน และการเปลี่ยนแปลงการขึ้นต่อกัน ใช้เป็นหลักฐานการเผยแพร่เท่านั้น รายงานการเปลี่ยนแปลงการขึ้นต่อกันจะเปรียบเทียบรุ่นผู้สมัครกับแท็กรุ่นเผยแพร่ก่อนหน้าที่เข้าถึงได้ การตรวจสอบเบื้องต้นจะอัปโหลดหลักฐานการขึ้นต่อกันเป็น openclaw-release-dependency-evidence-<tag> และฝังไว้ภายใต้ dependency-evidence/ ภายในอาร์ติแฟกต์การตรวจสอบเบื้องต้นของ npm ที่จัดเตรียมไว้ด้วย เส้นทางเผยแพร่จริงจะใช้อาร์ติแฟกต์การตรวจสอบเบื้องต้นนั้นซ้ำ จากนั้นแนบหลักฐานเดียวกันกับรุ่นเผยแพร่บน GitHub เป็น openclaw-<version>-dependency-evidence.zip
เรียกใช้ OpenClaw Release Publish สำหรับลำดับการเผยแพร่ที่มีการเปลี่ยนแปลงหลังจากมีแท็กแล้ว ส่งงานเผยแพร่รุ่นเบตาและรุ่นเสถียรตามปกติจาก main ที่เชื่อถือได้ โดยแท็กรุ่นเผยแพร่ยังคงเลือกคอมมิตเป้าหมายที่แน่นอนและอาจชี้ไปยัง release/YYYY.M.PATCH การเผยแพร่รุ่นแอลฟาของ Tideclaw ยังคงอยู่บนสาขาแอลฟาที่ตรงกัน ส่งค่า preflight_run_id ของ npm สำหรับ OpenClaw ที่สำเร็จ, full_release_validation_run_id ที่สำเร็จ และ full_release_validation_run_attempt ที่แน่นอน และคงขอบเขตการเผยแพร่ Plugin เริ่มต้นเป็น all-publishable เว้นแต่ว่าคุณกำลังดำเนินการซ่อมแซมแบบเจาะจงโดยตั้งใจ เวิร์กโฟลว์จะจัดลำดับการเผยแพร่ Plugin ไปยัง npm, การเผยแพร่ Plugin ไปยัง ClawHub และการเผยแพร่ OpenClaw ไปยัง npm เพื่อไม่ให้แพ็กเกจแกนหลักถูกเผยแพร่ก่อน Plugin ที่แยกออกเป็นภายนอก ส่วนการโปรโมต Windows และ Android จะทำงานพร้อมกับการเผยแพร่ npm ของแกนหลักโดยอ้างอิงหน้ารุ่นเผยแพร่ฉบับร่าง การเรียกเผยแพร่ซ้ำสามารถดำเนินต่อได้: เวอร์ชัน npm ของแกนหลักที่เผยแพร่แล้วจะข้ามการส่งงานแกนหลัก หลังเวิร์กโฟลว์พิสูจน์ว่า tarball ในรีจิสทรีตรงกับอาร์ติแฟกต์การตรวจสอบเบื้องต้นของแท็ก และจะข้ามการโปรโมต Windows/Android เมื่อรุ่นเผยแพร่มีสัญญาอาร์ติแฟกต์ที่ตรวจสอบแล้ว ดังนั้นการลองใหม่จะทำซ้ำเฉพาะขั้นตอนที่ล้มเหลว การซ่อมแซมเฉพาะ Plugin แบบเจาะจงต้องใช้ plugin_publish_scope=selected และรายการ Plugin ที่ไม่ว่าง การทำงานเฉพาะ Plugin แบบ all-publishable ต้องมีหลักฐานการตรวจสอบเบื้องต้นที่ครบถ้วนและเปลี่ยนแปลงไม่ได้ รวมถึงหลักฐานจากการตรวจสอบรุ่นเผยแพร่แบบเต็ม ระบบจะปฏิเสธหลักฐานที่ไม่ครบถ้วน
OpenClaw Release Publish สำหรับรุ่นเสถียรต้องระบุ windows_node_tag ที่แน่นอน หลังจากมีรุ่นเผยแพร่ openclaw/openclaw-windows-node แบบไม่ใช่รุ่นก่อนเผยแพร่ที่ตรงกัน พร้อมแผนที่ windows_node_installer_digests ที่ได้รับอนุมัติสำหรับรุ่นผู้สมัคร ก่อนส่งงานเผยแพร่ลูกใด ๆ ระบบจะตรวจสอบว่ารุ่นเผยแพร่ต้นทางนั้นเผยแพร่แล้ว ไม่ใช่รุ่นก่อนเผยแพร่ มีตัวติดตั้ง x64/ARM64 ที่จำเป็น และยังคงตรงกับแผนที่ที่อนุมัตินั้น จากนั้นระบบจะส่งงาน Windows Node Release ขณะที่รุ่นเผยแพร่ OpenClaw ยังเป็นฉบับร่าง โดยส่งต่อแผนที่ไดเจสต์ของตัวติดตั้งที่ตรึงไว้โดยไม่เปลี่ยนแปลง เวิร์กโฟลว์ลูกจะดาวน์โหลดตัวติดตั้ง Windows Hub ที่ลงนามแล้วจากแท็กที่ระบุแน่นอนนั้น ตรวจสอบให้ตรงกับไดเจสต์ที่ตรึงไว้ ยืนยันบนตัวรัน Windows ว่าลายเซ็น Authenticode ใช้ผู้ลงนาม OpenClaw Foundation ที่คาดไว้ เขียนแมนิเฟสต์ SHA-256 และอัปโหลดตัวติดตั้งพร้อมแมนิเฟสต์ไปยังรุ่นเผยแพร่ OpenClaw ที่เป็นมาตรฐานบน GitHub จากนั้นดาวน์โหลดอาร์ติแฟกต์ที่โปรโมตแล้วอีกครั้ง และตรวจสอบการเป็นสมาชิกในแมนิเฟสต์กับค่าแฮช ส่วนเวิร์กโฟลว์แม่จะตรวจสอบสัญญาอาร์ติแฟกต์ x64, ARM64 และเช็กซัมปัจจุบันก่อนเผยแพร่ การกู้คืนโดยตรงจะปฏิเสธชื่ออาร์ติแฟกต์ OpenClawCompanion-* ที่ไม่คาดไว้ ก่อนแทนที่อาร์ติแฟกต์ตามสัญญาที่คาดไว้ด้วยไบต์ต้นทางที่ตรึงไว้

ส่งงาน Windows Node Release ด้วยตนเองเฉพาะเพื่อการกู้คืน และส่งแท็กที่แน่นอนเสมอ ห้ามใช้ latest พร้อมแผนที่ JSON expected_installer_digests ที่ระบุชัดเจนจากรุ่นเผยแพร่ต้นทางที่อนุมัติ ลิงก์ดาวน์โหลดบนเว็บไซต์ควรชี้ไปยัง URL ของอาร์ติแฟกต์รุ่นเผยแพร่ OpenClaw ที่แน่นอนสำหรับรุ่นเสถียรปัจจุบัน หรือใช้ releases/latest/download/... หลังจากตรวจสอบแล้วเท่านั้นว่าการเปลี่ยนเส้นทางล่าสุดของ GitHub ชี้ไปยังรุ่นเผยแพร่เดียวกัน ห้ามลิงก์ไปยังหน้ารุ่นเผยแพร่ของที่เก็บคู่หูเพียงอย่างเดียว
ขณะนี้การตรวจสอบรีลีสทำงานในเวิร์กโฟลว์แบบเรียกใช้ด้วยตนเองแยกต่างหาก: OpenClaw Release Checks นอกจากนี้ยังเรียกใช้เลนความสอดคล้องของม็อก QA Lab รวมถึงโปรไฟล์ Matrix แบบใช้งานจริงที่รวดเร็วและเลน QA ของ Telegram ก่อนอนุมัติรีลีส เลนแบบใช้งานจริงใช้สภาพแวดล้อม qa-live-shared ส่วน Telegram ยังใช้การเช่าข้อมูลรับรอง Convex CI ด้วย เรียกใช้เวิร์กโฟลว์ QA-Lab - All Lanes แบบเรียกใช้ด้วยตนเองโดยกำหนด matrix_profile=all และ matrix_shards=true เมื่อต้องการตรวจสอบรายการขนส่ง สื่อ และ E2EE ของ Matrix ทั้งหมดพร้อมกัน
การตรวจสอบรันไทม์สำหรับการติดตั้งและอัปเกรดข้ามระบบปฏิบัติการเป็นส่วนหนึ่งของ OpenClaw Release Checks และ Full Release Validation แบบสาธารณะ ซึ่งเรียกเวิร์กโฟลว์ที่นำกลับมาใช้ซ้ำได้ .github/workflows/openclaw-cross-os-release-checks-reusable.yml โดยตรง การแยกนี้เป็นไปโดยเจตนา เพื่อให้เส้นทางรีลีส npm จริงสั้น กำหนดผลได้แน่นอน และมุ่งเน้นอาร์ติแฟกต์ ขณะที่การตรวจสอบแบบใช้งานจริงที่ช้ากว่าจะอยู่ในเลนของตนเอง จึงไม่ทำให้การเผยแพร่หยุดชะงักหรือถูกบล็อก
ควรสั่งรันการตรวจสอบรีลีสที่ใช้ข้อมูลลับผ่าน Full Release Validation หรือจากรีเฟอเรนซ์เวิร์กโฟลว์ main/รีลีส เพื่อให้ตรรกะเวิร์กโฟลว์และข้อมูลลับยังคงอยู่ภายใต้การควบคุม
OpenClaw Release Checks รับชื่อบรานช์ แท็ก หรือ SHA แบบเต็มของคอมมิต ตราบใดที่คอมมิตที่ได้สามารถเข้าถึงได้จากบรานช์หรือแท็กรีลีสของ OpenClaw
ขั้นเตรียมตรวจสอบแบบไม่เผยแพร่ของ OpenClaw NPM Release ยังรับ SHA แบบเต็ม 40 อักขระของคอมมิตในบรานช์เวิร์กโฟลว์ปัจจุบัน โดยไม่ต้องมีแท็กที่พุชแล้ว เส้นทาง SHA นี้ใช้ได้เฉพาะการตรวจสอบและไม่สามารถเลื่อนขั้นเป็นการเผยแพร่จริงได้ ในโหมด SHA เวิร์กโฟลว์จะสร้าง v<package.json version> ขึ้นเฉพาะสำหรับการตรวจสอบเมทาดาทาของแพ็กเกจเท่านั้น การเผยแพร่จริงยังคงต้องใช้แท็กรีลีสจริง
ทั้งสองเวิร์กโฟลว์ให้เส้นทางการเผยแพร่และการเลื่อนขั้นจริงทำงานบนรันเนอร์ที่โฮสต์โดย GitHub ขณะที่เส้นทางตรวจสอบที่ไม่แก้ไขข้อมูลสามารถใช้รันเนอร์ Blacksmith Linux ที่มีขนาดใหญ่กว่าได้
เวิร์กโฟลว์ดังกล่าวเรียกใช้ OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache โดยใช้ข้อมูลลับของเวิร์กโฟลว์ทั้ง OPENAI_API_KEY และ ANTHROPIC_API_KEY
ขั้นเตรียมตรวจสอบรีลีส npm ไม่รอเลนตรวจสอบรีลีสที่แยกต่างหากอีกต่อไป
ก่อนติดแท็กรีลีสแคนดิเดตในเครื่อง ให้เรียกใช้ RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check ตัวช่วยจะเรียกใช้มาตรการป้องกันรีลีสแบบรวดเร็ว การตรวจสอบรีลีส npm/ClawHub ของ Plugin การบิลด์ การบิลด์ UI และ release:openclaw:npm:check ตามลำดับที่ช่วยตรวจจับข้อผิดพลาดทั่วไปซึ่งอาจขัดขวางการอนุมัติก่อนที่เวิร์กโฟลว์เผยแพร่ของ GitHub จะเริ่มทำงาน
เรียกใช้ RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (หรือแท็กพรีรีลีส/แท็กแก้ไขที่ตรงกัน) ก่อนอนุมัติ
หลังเผยแพร่ npm ให้เรียกใช้ node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (หรือเวอร์ชันเบตา/เวอร์ชันแก้ไขที่ตรงกัน) เพื่อตรวจสอบเส้นทางการติดตั้งจากรีจิสทรีที่เผยแพร่แล้วในคำนำหน้าชั่วคราวใหม่
หลังเผยแพร่เบตา ให้เรียกใช้ OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live เพื่อตรวจสอบการเริ่มต้นใช้งานแพ็กเกจที่ติดตั้ง การตั้งค่า Telegram และ E2E ของ Telegram จริงกับแพ็กเกจ npm ที่เผยแพร่แล้ว โดยใช้พูลข้อมูลรับรอง Telegram แบบเช่าร่วมกัน สำหรับการเรียกใช้ครั้งเดียวในเครื่องของผู้ดูแล อาจละตัวแปร Convex และส่งข้อมูลรับรองสภาพแวดล้อม OPENCLAW_QA_TELEGRAM_* ทั้งสามรายการโดยตรง
หากต้องการเรียกใช้การทดสอบควันหลังเผยแพร่เบตาแบบเต็มจากเครื่องของผู้ดูแล ให้ใช้ pnpm release:beta-smoke -- --beta betaN ตัวช่วยจะเรียกใช้การตรวจสอบการอัปเดต npm และเป้าหมายใหม่ของ Parallels สั่งรัน NPM Telegram Beta E2E สำรวจสถานะการทำงานของเวิร์กโฟลว์ที่ตรงกัน ดาวน์โหลดอาร์ติแฟกต์ และพิมพ์รายงาน Telegram
ผู้ดูแลสามารถเรียกใช้การตรวจสอบหลังเผยแพร่แบบเดียวกันจาก GitHub Actions ผ่านเวิร์กโฟลว์ NPM Telegram Beta E2E แบบเรียกใช้ด้วยตนเอง เวิร์กโฟลว์นี้จงใจให้เรียกใช้ด้วยตนเองเท่านั้นและไม่ทำงานทุกครั้งที่มีการผสาน
ระบบอัตโนมัติสำหรับรีลีสของผู้ดูแลใช้กระบวนการเตรียมตรวจสอบแล้วจึงเลื่อนขั้น:
- การเผยแพร่ npm จริงต้องมี preflight_run_id ของ npm ที่สำเร็จ
- การประสานงานเผยแพร่เบตาและเวอร์ชันเสถียรตามปกติ รวมถึงขั้นเตรียมตรวจสอบ ใช้ main ที่เชื่อถือได้กับแท็กเป้าหมายที่ตรงกันทุกประการ การเผยแพร่และขั้นเตรียมตรวจสอบอัลฟาของ Tideclaw ใช้บรานช์อัลฟาที่ตรงกัน
- รีลีส npm แบบเสถียรใช้ beta เป็นค่าเริ่มต้น การเผยแพร่ npm แบบเสถียรสามารถกำหนดเป้าหมายเป็น latest อย่างชัดเจนผ่านอินพุตของเวิร์กโฟลว์
- การแก้ไข dist-tag ของ npm โดยใช้โทเค็นอยู่ใน openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml เนื่องจาก npm dist-tag add ยังคงต้องใช้ NPM_TOKEN ขณะที่รีโพซิทอรีต้นทางยังคงเผยแพร่ด้วย OIDC เท่านั้น
- macOS Release แบบสาธารณะใช้สำหรับการตรวจสอบเท่านั้น เมื่อแท็กอยู่เฉพาะบนบรานช์รีลีส แต่เวิร์กโฟลว์ถูกสั่งรันจาก main ให้ตั้งค่า public_release_branch=release/YYYY.M.PATCH
- การเผยแพร่ macOS จริงต้องมี preflight_run_id และ validate_run_id ของ macOS ที่สำเร็จ
- เส้นทางเผยแพร่จริงเลื่อนขั้นอาร์ติแฟกต์ที่เตรียมไว้แทนการบิลด์ใหม่อีกครั้ง
สำหรับรีลีสแก้ไขเวอร์ชันเสถียร เช่น YYYY.M.PATCH-N ตัวตรวจสอบหลังเผยแพร่จะตรวจสอบเส้นทางอัปเกรดในคำนำหน้าชั่วคราวเดียวกันจาก YYYY.M.PATCH เป็น YYYY.M.PATCH-N ด้วย เพื่อไม่ให้การแก้ไขรีลีสปล่อยให้การติดตั้งแบบส่วนกลางรุ่นเก่ายังคงใช้เพย์โหลดเวอร์ชันเสถียรพื้นฐานโดยไม่มีการแจ้งเตือน
ขั้นเตรียมตรวจสอบรีลีส npm จะปฏิเสธโดยค่าเริ่มต้น เว้นแต่ทาร์บอลจะมีทั้ง dist/control-ui/index.html และเพย์โหลด dist/control-ui/assets/ ที่ไม่ว่างเปล่า เพื่อไม่ให้เราจัดส่งแดชบอร์ดเบราว์เซอร์ที่ว่างเปล่าอีก
การตรวจสอบหลังเผยแพร่ยังตรวจสอบว่าจุดเข้าใช้งานของ Plugin และเมทาดาทาของแพ็กเกจที่เผยแพร่มีอยู่ในโครงสร้างรีจิสทรีที่ติดตั้งแล้ว รีลีสที่ไม่มีเพย์โหลดรันไทม์ของ Plugin จะไม่ผ่านตัวตรวจสอบหลังเผยแพร่และไม่สามารถเลื่อนขั้นเป็น latest ได้
pnpm test:install:smoke ยังบังคับใช้งบประมาณ unpackedSize ของ npm pack กับทาร์บอลอัปเดตที่เป็นตัวเลือก เพื่อให้ E2E ของตัวติดตั้งตรวจจับการขยายขนาดแพ็กโดยไม่ตั้งใจก่อนเข้าสู่เส้นทางเผยแพร่รีลีส
หากงานรีลีสแก้ไขการวางแผน CI ไฟล์แมนิเฟสต์การกำหนดเวลาของส่วนขยาย หรือเมทริกซ์การทดสอบส่วนขยาย ให้สร้างใหม่และตรวจสอบเอาต์พุตเมทริกซ์ plugin-prerelease-extension-shard ที่ตัววางแผนเป็นเจ้าของจาก .github/workflows/plugin-prerelease.yml ก่อนอนุมัติ เพื่อไม่ให้บันทึกประจำรุ่นอธิบายโครงสร้าง CI ที่ล้าสมัย
ความพร้อมของรีลีส macOS แบบเสถียรยังรวมพื้นผิวของตัวอัปเดตด้วย: รีลีส GitHub ต้องมีแพ็กเกจ .zip, .dmg และ .dSYM.zip ในท้ายที่สุด; appcast.xml บน main ต้องชี้ไปยังไฟล์ zip เวอร์ชันเสถียรใหม่หลังเผยแพร่ (เวิร์กโฟลว์เผยแพร่ macOS จะคอมมิตให้อัตโนมัติ หรือเปิด PR สำหรับ appcast เมื่อถูกบล็อกไม่ให้พุชโดยตรง); แอปที่แพ็กแล้วต้องคงรหัสบันเดิลที่ไม่ใช่ดีบัก, URL ฟีด Sparkle ที่ไม่ว่างเปล่า และ CFBundleVersion ที่ไม่น้อยกว่าค่าขั้นต่ำมาตรฐานของบิลด์ Sparkle สำหรับเวอร์ชันรีลีสนั้น

กล่องทดสอบรีลีส

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

bash

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

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

สำหรับการตรวจสอบบรานช์หรือแท็กรีลีส ให้เรียกใช้จากรีเฟอเรนซ์เวิร์กโฟลว์ main ที่เชื่อถือได้ และส่งบรานช์หรือแท็กรีลีสเป็น 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 \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N

เวิร์กโฟลว์จะแปลงรีเฟอเรนซ์เป้าหมาย สั่งรัน CI แบบเรียกใช้ด้วยตนเองโดยกำหนด target_ref=<release-ref> แล้วจึงสั่งรัน OpenClaw Release Checks โดย OpenClaw Release Checks จะแยกงานออกเป็นการทดสอบควันของการติดตั้ง การตรวจสอบรีลีสข้ามระบบปฏิบัติการ ความครอบคลุมเส้นทางรีลีส Docker แบบใช้งานจริง/E2E เมื่อเปิดใช้การทดสอบต่อเนื่อง Package Acceptance พร้อม E2E แพ็กเกจ Telegram มาตรฐาน ความสอดคล้องของ QA Lab, Matrix แบบใช้งานจริง และ Telegram แบบใช้งานจริง การทำงานแบบเต็ม/ทั้งหมดจะยอมรับได้ก็ต่อเมื่อสรุป Full Release Validation แสดงว่า normal_ci, plugin_prerelease และ release_checks สำเร็จ เว้นแต่การเรียกใช้ซ้ำแบบเจาะจงจะตั้งใจข้ามเวิร์กโฟลว์ลูก Plugin Prerelease ที่แยกต่างหาก ใช้เวิร์กโฟลว์ลูก npm-telegram แบบเดี่ยวเฉพาะสำหรับการเรียกใช้แพ็กเกจที่เผยแพร่แล้วซ้ำแบบเจาะจง โดยกำหนด release_package_spec หรือ npm_telegram_package_spec สรุปจากตัวตรวจสอบขั้นสุดท้ายมีตารางงานที่ช้าที่สุดสำหรับการทำงานของเวิร์กโฟลว์ลูกแต่ละรายการ เพื่อให้ผู้จัดการรีลีสเห็นเส้นทางวิกฤตปัจจุบันโดยไม่ต้องดาวน์โหลดบันทึก

เวิร์กโฟลว์ลูกด้านประสิทธิภาพผลิตภัณฑ์ใช้เฉพาะอาร์ติแฟกต์ในเส้นทางรีลีสนี้ เวิร์กโฟลว์ครอบจะสั่งรันโดยกำหนด publish_reports=false และการตรวจสอบจะถูกปฏิเสธ เว้นแต่มาตรการป้องกันโหมดอาร์ติแฟกต์เท่านั้นจะพิสูจน์ว่าตัวเผยแพร่รายงาน Clawgrit ยังคงถูกข้าม

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

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

ใช้ release_profile เพื่อเลือกขอบเขตการใช้งานจริง/ผู้ให้บริการ:

minimum: เส้นทาง OpenAI/แกนหลักแบบใช้งานจริงและ Docker ที่สำคัญต่อรีลีสและรวดเร็วที่สุด
stable: ขั้นต่ำรวมกับความครอบคลุมผู้ให้บริการ/แบ็กเอนด์แบบเสถียรสำหรับการอนุมัติรีลีส
full: แบบเสถียรรวมกับความครอบคลุมผู้ให้บริการ/สื่อเชิงแนะนำในวงกว้าง

การตรวจสอบแบบเสถียรและแบบเต็มจะเรียกใช้การกวาดตรวจสอบแบบใช้งานจริง/E2E อย่างละเอียด เส้นทางรีลีส Docker และการอยู่รอดหลังอัปเกรดแพ็กเกจที่เผยแพร่ภายในขอบเขตทุกครั้งก่อนเลื่อนขั้น ใช้ run_release_soak=true เพื่อร้องขอการกวาดตรวจสอบเดียวกันสำหรับเบตา การกวาดตรวจสอบนี้ครอบคลุมแพ็กเกจเสถียรล่าสุดสี่รายการ รวมถึงค่าฐาน 2026.4.23 และ 2026.5.2 ที่ตรึงไว้ พร้อมความครอบคลุม 2026.4.15 ที่เก่ากว่า โดยนำค่าฐานที่ซ้ำกันออกและแบ่งแต่ละค่าฐานเป็นงานรันเนอร์ Docker ของตนเอง

OpenClaw Release Checks ใช้รีเฟอเรนซ์เวิร์กโฟลว์ที่เชื่อถือได้เพื่อแปลงรีเฟอเรนซ์เป้าหมายเพียงครั้งเดียวเป็น release-package-under-test และนำอาร์ติแฟกต์นั้นกลับมาใช้ในการตรวจสอบข้ามระบบปฏิบัติการ Package Acceptance และการตรวจสอบ Docker ตามเส้นทางรีลีสเมื่อมีการทดสอบต่อเนื่อง วิธีนี้ทำให้กล่องทดสอบที่เกี่ยวข้องกับแพ็กเกจทั้งหมดใช้ไบต์ชุดเดียวกันและหลีกเลี่ยงการบิลด์แพ็กเกจซ้ำ หลังจากเบตาอยู่บน npm แล้ว ให้ตั้งค่า release_package_spec=openclaw@YYYY.M.PATCH-beta.N เพื่อให้การตรวจสอบรีลีสดาวน์โหลดแพ็กเกจที่จัดส่งแล้วเพียงครั้งเดียว แยก SHA ของซอร์สบิลด์จาก dist/build-info.json และนำอาร์ติแฟกต์นั้นกลับมาใช้สำหรับเลนข้ามระบบปฏิบัติการ Package Acceptance, Docker ตามเส้นทางรีลีส และ Telegram ของแพ็กเกจ

การทดสอบควันการติดตั้ง OpenAI ข้ามระบบปฏิบัติการใช้ OPENCLAW_CROSS_OS_OPENAI_MODEL เมื่อตั้งค่าตัวแปรระดับรีโพซิทอรี/องค์กร มิฉะนั้นจะใช้ openai/gpt-5.6-luna เนื่องจากเลนนี้มีไว้เพื่อพิสูจน์การติดตั้งแพ็กเกจ การเริ่มต้นใช้งาน การเริ่มทำงานของ Gateway และการทำงานของเอเจนต์แบบใช้งานจริงหนึ่งรอบ ไม่ใช่เพื่อวัดประสิทธิภาพของโมเดลที่มีความสามารถสูงสุด เมทริกซ์ผู้ให้บริการแบบใช้งานจริงที่กว้างกว่ายังคงเป็นพื้นที่สำหรับความครอบคลุมเฉพาะโมเดล

ใช้รูปแบบต่อไปนี้ตามขั้นตอนของรีลีส:

bash

# Validate an unpublished release candidate branch.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 # 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.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=full \  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f npm_telegram_provider_mode=mock-openai

อย่าใช้ชุดตรวจสอบรวมทั้งหมดเป็นการรันซ้ำครั้งแรกหลังจากแก้ไขเฉพาะจุด หากกล่องใดกล่องหนึ่งล้มเหลว ให้ใช้เวิร์กโฟลว์ย่อย งาน เลน Docker โปรไฟล์แพ็กเกจ ผู้ให้บริการโมเดล หรือเลน QA ที่ล้มเหลวสำหรับการพิสูจน์ครั้งถัดไป รันชุดตรวจสอบรวมทั้งหมดอีกครั้งเฉพาะเมื่อการแก้ไขเปลี่ยนการประสานงานรุ่นที่ใช้ร่วมกัน หรือทำให้หลักฐานจากทุกกล่องก่อนหน้านี้ล้าสมัย ตัวตรวจสอบขั้นสุดท้ายของชุดรวมจะตรวจสอบรหัสการรันของเวิร์กโฟลว์ย่อยที่บันทึกไว้อีกครั้ง ดังนั้นหลังจากรันเวิร์กโฟลว์ย่อยซ้ำสำเร็จแล้ว ให้รันซ้ำเฉพาะงานแม่ Verify full validation ที่ล้มเหลว

rerun_group=all อาจนำการรันชุดรวมที่ผ่านก่อนหน้ามาใช้ซ้ำได้ เฉพาะเมื่อการรันนั้นตรวจสอบ SHA เป้าหมาย โปรไฟล์รุ่น การตั้งค่าการทดสอบต่อเนื่องที่มีผล และอินพุตการตรวจสอบเดียวกันทุกประการ นี่คือการกู้คืนแบบจำกัดขอบเขตสำหรับการรันตัวเลือกเดิมซ้ำ ไม่ใช่การนำหลักฐานข้าม SHA มาใช้ซ้ำ สำหรับตัวเลือกที่เปลี่ยนไป รวมถึงคอมมิตที่เปลี่ยนเฉพาะบันทึกการเปลี่ยนแปลงหรือเวอร์ชัน ให้รันเกตแพ็กเกจ อาร์ติแฟกต์ การติดตั้ง Docker หรือผู้ให้บริการทุกเกตที่ได้รับผลกระทบจากพาธหรือแฮชอาร์ติแฟกต์ที่เปลี่ยนไปอีกครั้ง การรันชุดรวมที่ใหม่กว่าสำหรับอ้างอิง release/* และกลุ่มการรันซ้ำเดียวกัน จะแทนที่การรันที่กำลังดำเนินอยู่โดยอัตโนมัติ ส่ง reuse_evidence=false เพื่อบังคับให้รันใหม่ทั้งหมด

สำหรับการกู้คืนแบบจำกัดขอบเขต ให้ส่ง rerun_group ไปยังชุดรวม all คือการรันตัวเลือกรุ่นจริง ci รันเฉพาะเวิร์กโฟลว์ย่อย CI ปกติ plugin-prerelease รันเฉพาะเวิร์กโฟลว์ย่อย Plugin สำหรับรุ่นเท่านั้น release-checks รันกล่องรุ่นทุกกล่อง และกลุ่มรุ่นที่แคบกว่าคือ install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live และ npm-telegram การรัน npm-telegram ซ้ำแบบเฉพาะจุดต้องมี release_package_spec หรือ npm_telegram_package_spec ส่วนการรันแบบเต็ม/ทั้งหมดจะใช้ E2E ของ Telegram สำหรับแพ็กเกจมาตรฐานภายใน Package Acceptance การรันข้ามระบบปฏิบัติการซ้ำแบบเฉพาะจุดสามารถเพิ่ม cross_os_suite_filter=windows/packaged-upgrade หรือตัวกรองระบบปฏิบัติการ/ชุดทดสอบอื่นได้ ความล้มเหลวของการตรวจสอบรุ่นใน QA จะขัดขวางการตรวจสอบรุ่นตามปกติ รวมถึงความคลาดเคลื่อนของเครื่องมือแบบไดนามิกของ OpenClaw ที่จำเป็นในระดับมาตรฐาน การรันอัลฟาของ Tideclaw อาจยังถือว่าเลนตรวจสอบรุ่นที่ไม่เกี่ยวกับความปลอดภัยของแพ็กเกจเป็นเพียงคำแนะนำ เมื่อใช้ release_profile=beta ชุดทดสอบผู้ให้บริการจริงของ Run repo/live E2E validation จะเป็นเพียงคำแนะนำ (แจ้งเตือนแต่ไม่ขัดขวาง) ส่วนโปรไฟล์ stable และ full ยังคงให้ชุดเหล่านี้เป็นตัวขัดขวาง เมื่อ live_suite_filter ร้องขอเลน QA แบบใช้งานจริงที่มีเกตอย่างชัดเจน เช่น Discord, WhatsApp หรือ Slack ต้องเปิดใช้ตัวแปรรีโป OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED ที่ตรงกัน มิฉะนั้นการรับอินพุตจะล้มเหลวแทนที่จะข้ามเลนนั้นโดยไม่แจ้ง

Vitest

กล่อง Vitest คือเวิร์กโฟลว์ย่อย CI แบบเรียกด้วยตนเอง CI แบบเรียกด้วยตนเองตั้งใจข้ามการจำกัดขอบเขตตามการเปลี่ยนแปลง และบังคับใช้กราฟการทดสอบปกติสำหรับตัวเลือกรุ่น ได้แก่ ชาร์ด Linux Node, ชาร์ด Plugin ที่รวมมาให้, ชาร์ดสัญญาของ Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, check-*, check-additional-*, การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ที่บิลด์แล้ว, การตรวจสอบเอกสาร, Skills ของ Python, Windows, macOS และการรองรับหลายภาษาของ Control UI โดยจะรวม Android เมื่อ Full Release Validation รันกล่องนี้ เพราะชุดรวมส่ง include_android=true ส่วน CI แบบเรียกด้วยตนเองโดยอิสระต้องใช้ include_android=true เพื่อให้ครอบคลุม Android

ใช้กล่องนี้เพื่อตอบว่า "โครงสร้างซอร์สผ่านชุดทดสอบปกติทั้งหมดหรือไม่" ซึ่งไม่เหมือนกับการตรวจสอบผลิตภัณฑ์ตามเส้นทางรุ่น หลักฐานที่ต้องเก็บไว้:

สรุป Full Release Validation ที่แสดง URL ของการรัน CI ที่สั่งให้ทำงาน
การรัน CI ผ่านบน SHA เป้าหมายที่ตรงกันทุกประการ
ชื่อชาร์ดที่ล้มเหลวหรือทำงานช้าจากงาน CI เมื่อตรวจสอบการถดถอย
อาร์ติแฟกต์เวลาการทำงานของ Vitest เช่น .artifacts/vitest-shard-timings.json เมื่อการรันต้องมีการวิเคราะห์ประสิทธิภาพ

รัน CI แบบเรียกด้วยตนเองโดยตรงเฉพาะเมื่อรุ่นต้องการ CI ปกติที่ให้ผลแน่นอน แต่ไม่ต้องใช้กล่อง Docker, QA Lab, การทดสอบจริง, ข้ามระบบปฏิบัติการ หรือแพ็กเกจ ใช้คำสั่งแรกสำหรับ CI โดยตรงที่ไม่รวม Android เพิ่ม include_android=true เมื่อ CI โดยตรงสำหรับตัวเลือกรุ่นต้องครอบคลุม Android:

bash

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

กล่อง Docker อยู่ใน OpenClaw Release Checks ผ่าน openclaw-live-and-e2e-checks-reusable.yml รวมถึงเวิร์กโฟลว์ install-smoke ในโหมดรุ่น กล่องนี้ตรวจสอบตัวเลือกรุ่นผ่านสภาพแวดล้อม Docker แบบแพ็กเกจ แทนที่จะใช้เฉพาะการทดสอบระดับซอร์ส

ความครอบคลุมของ Docker สำหรับรุ่นประกอบด้วย:

การตรวจสอบการติดตั้งแบบเต็ม โดยเปิดใช้การตรวจสอบการติดตั้ง Bun แบบส่วนกลางที่ทำงานช้า
การเตรียม/นำอิมเมจตรวจสอบเบื้องต้นจาก Dockerfile รากมาใช้ซ้ำตาม SHA เป้าหมาย โดยงานตรวจสอบ QR, root/gateway และตัวติดตั้ง/Bun จะทำงานเป็นชาร์ด install-smoke แยกกัน
เลน E2E ของรีโพซิทอรี
ส่วน Docker สำหรับเส้นทางรุ่น: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a ถึง plugins-runtime-install-h และ openwebui
ความครอบคลุมของ OpenWebUI บนรันเนอร์ดิสก์ขนาดใหญ่โดยเฉพาะเมื่อมีการร้องขอ
เลนติดตั้ง/ถอนการติดตั้ง Plugin ที่รวมมาให้แบบแบ่งส่วน bundled-plugin-install-uninstall-0 ถึง bundled-plugin-install-uninstall-23
ชุดทดสอบผู้ให้บริการแบบใช้งานจริง/E2E และความครอบคลุมโมเดลจริงใน Docker เมื่อการตรวจสอบรุ่นรวมชุดทดสอบจริง

ใช้อาร์ติแฟกต์ Docker ก่อนรันซ้ำ ตัวจัดกำหนดการเส้นทางรุ่นจะอัปโหลด .artifacts/docker-tests/ ซึ่งมีบันทึกของเลน, summary.json, failures.json, เวลาของแต่ละระยะ, JSON แผนของตัวจัดกำหนดการ และคำสั่งรันซ้ำ สำหรับการกู้คืนแบบเฉพาะจุด ให้ใช้ docker_lanes=<lane[,lane]> กับเวิร์กโฟลว์แบบใช้ซ้ำสำหรับการทดสอบจริง/E2E แทนการรันส่วนรุ่นทั้งหมดซ้ำ คำสั่งรันซ้ำที่สร้างขึ้นจะรวม package_artifact_run_id ก่อนหน้าและอินพุตอิมเมจ Docker ที่เตรียมไว้เมื่อมี เพื่อให้เลนที่ล้มเหลวสามารถนำ tarball และอิมเมจ GHCR ชุดเดิมมาใช้ซ้ำได้

QA Lab

กล่อง QA Lab เป็นส่วนหนึ่งของ OpenClaw Release Checks เช่นกัน นี่คือเกตระดับรุ่นสำหรับพฤติกรรมแบบเอเจนต์และระดับช่องทาง ซึ่งแยกจาก Vitest และกลไกแพ็กเกจของ Docker

ความครอบคลุมของ QA Lab สำหรับรุ่นประกอบด้วย:

เลนความสอดคล้องแบบจำลองที่เปรียบเทียบเลนตัวเลือก OpenAI กับค่าฐาน anthropic/claude-opus-4-8 โดยใช้ชุดความสอดคล้องแบบเอเจนต์
โปรไฟล์ Matrix QA แบบใช้งานจริงที่รวดเร็ว โดยใช้สภาพแวดล้อม qa-live-shared
เลน Telegram QA แบบใช้งานจริง โดยใช้การเช่าข้อมูลประจำตัว CI จาก Convex
pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke หรือ pnpm qa:observability:smoke เมื่อระบบโทรมาตรของรุ่นต้องการหลักฐานในเครื่องอย่างชัดเจน

ใช้กล่องนี้เพื่อตอบว่า "รุ่นทำงานอย่างถูกต้องในสถานการณ์ QA และโฟลว์ช่องทางจริงหรือไม่" เก็บ URL อาร์ติแฟกต์สำหรับเลนความสอดคล้อง Matrix และ Telegram ไว้เมื่ออนุมัติรุ่น ความครอบคลุม Matrix แบบเต็มยังคงใช้งานได้ในรูปแบบการรัน QA-Lab แบบแบ่งชาร์ดด้วยตนเอง แทนที่จะเป็นเลนเริ่มต้นที่มีความสำคัญต่อรุ่น

แพ็กเกจ

กล่องแพ็กเกจคือเกตสำหรับผลิตภัณฑ์ที่ติดตั้งได้ โดยมี Package Acceptance และตัวแก้ไข scripts/resolve-openclaw-package-candidate.mjs รองรับ ตัวแก้ไขจะปรับตัวเลือกให้อยู่ในรูป tarball package-under-test ที่ Docker E2E ใช้งาน ตรวจสอบรายการภายในแพ็กเกจ บันทึกเวอร์ชันแพ็กเกจและ SHA-256 และแยกอ้างอิงของชุดเครื่องมือเวิร์กโฟลว์ออกจากอ้างอิงซอร์สแพ็กเกจ

แหล่งที่มาของตัวเลือกที่รองรับ:

source=npm: openclaw@beta, openclaw@latest หรือเวอร์ชันรุ่น OpenClaw ที่ระบุแน่นอน
source=ref: แพ็กสาขา แท็ก หรือ SHA คอมมิตแบบเต็มของ package_ref ที่เชื่อถือได้ ด้วยชุดเครื่องมือ workflow_ref ที่เลือก
source=url: ดาวน์โหลด .tgz ผ่าน HTTPS แบบสาธารณะ โดยต้องมี package_sha256 ระบบจะปฏิเสธข้อมูลประจำตัวใน URL, พอร์ต HTTPS ที่ไม่ใช่ค่าปริยาย, ชื่อโฮสต์หรือแอดเดรสที่แก้ไขแล้วซึ่งเป็นแบบส่วนตัว/ภายใน/การใช้งานพิเศษ และการเปลี่ยนเส้นทางที่ไม่ปลอดภัย
source=trusted-url: ดาวน์โหลด .tgz ผ่าน HTTPS โดยต้องมี package_sha256 และ trusted_source_id จากนโยบายที่ตั้งชื่อไว้ใน .github/package-trusted-sources.json ใช้ตัวเลือกนี้สำหรับมิเรอร์องค์กรหรือรีโพซิทอรีแพ็กเกจส่วนตัวที่ผู้ดูแลเป็นเจ้าของ แทนการเพิ่มการข้ามเครือข่ายส่วนตัวระดับอินพุตให้กับ source=url
source=artifact: นำ .tgz ที่อัปโหลดโดยการรัน GitHub Actions อื่นมาใช้ซ้ำ

OpenClaw Release Checks รัน Package Acceptance ด้วย source=artifact, อาร์ติแฟกต์แพ็กเกจรุ่นที่เตรียมไว้, suite_profile=custom, docker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape, telegram_mode=mock-openai Package Acceptance ยังคงทดสอบการย้ายข้อมูล การอัปเดต การอัปเกรด VPS ที่จัดการด้วยสิทธิ์ root การเริ่มทำงานใหม่หลังอัปเดตด้วยการยืนยันตัวตนที่กำหนดค่าไว้ การติดตั้ง skill จริงจาก ClawHub การล้างการขึ้นต่อกันของ Plugin ที่ล้าสมัย ฟิกซ์เจอร์ Plugin แบบออฟไลน์ การอัปเดต Plugin การเสริมความแข็งแกร่งต่อการหลบหนีจากการผูกคำสั่งของ Plugin และ QA ของแพ็กเกจ Telegram กับ tarball ที่แก้ไขแล้วชุดเดียวกัน การตรวจสอบรุ่นแบบขัดขวางใช้ค่าฐานแพ็กเกจล่าสุดที่เผยแพร่เป็นค่าปริยาย ส่วนโปรไฟล์ beta ที่ใช้ run_release_soak=true, release_profile=stable หรือ release_profile=full จะขยายการกวาดตรวจผู้รอดจากการอัปเกรดแพ็กเกจที่เผยแพร่ไปยัง last-stable-4 รวมถึงค่าฐาน 2026.4.23, 2026.5.2 และ 2026.4.15 ที่ตรึงไว้ พร้อมสถานการณ์ reported-issues ใช้ Package Acceptance กับ source=npm สำหรับตัวเลือกที่เผยแพร่แล้ว source=ref สำหรับ tarball npm ในเครื่องที่อ้างอิงด้วย SHA ก่อนเผยแพร่ source=trusted-url สำหรับมิเรอร์องค์กร/ส่วนตัวที่ผู้ดูแลเป็นเจ้าของ หรือ source=artifact สำหรับ tarball ที่เตรียมไว้และอัปโหลดโดยการรัน GitHub Actions อื่น

นี่คือสิ่งทดแทนที่ทำงานบน GitHub โดยตรงสำหรับความครอบคลุมแพ็กเกจ/การอัปเดตส่วนใหญ่ที่ก่อนหน้านี้ต้องใช้ Parallels การตรวจสอบรุ่นข้ามระบบปฏิบัติการยังคงสำคัญต่อการเริ่มต้นใช้งาน ตัวติดตั้ง และพฤติกรรมเฉพาะแพลตฟอร์ม แต่การตรวจสอบผลิตภัณฑ์ด้านแพ็กเกจ/การอัปเดตควรเลือกใช้ Package Acceptance

รายการตรวจสอบมาตรฐานสำหรับการตรวจสอบการอัปเดตและ Plugin คือ การทดสอบการอัปเดตและ Plugin ใช้รายการนี้เมื่อตัดสินใจว่าเลนในเครื่อง, Docker, Package Acceptance หรือการตรวจสอบรุ่นใดพิสูจน์การเปลี่ยนแปลงด้านการติดตั้ง/อัปเดต Plugin, การล้างข้อมูลด้วย doctor หรือการย้ายข้อมูลแพ็กเกจที่เผยแพร่ได้ การย้ายข้อมูลอัปเดตที่เผยแพร่แบบครบถ้วนจากทุกแพ็กเกจ stable ตั้งแต่ 2026.4.23+ เป็นเวิร์กโฟลว์ Update Migration แบบเรียกด้วยตนเองแยกต่างหาก ไม่ใช่ส่วนหนึ่งของ Full Release CI

การผ่อนปรนของ package-acceptance แบบเดิมถูกจำกัดเวลาไว้อย่างตั้งใจ แพ็กเกจจนถึง 2026.4.25 อาจใช้เส้นทางความเข้ากันได้สำหรับช่องว่างของเมทาดาทาที่เผยแพร่ไปยัง npm แล้ว ได้แก่ รายการคลัง QA ส่วนตัวที่หายไปจาก tarball, gateway install --wrapper ที่หายไป, ไฟล์แพตช์ที่หายไปในฟิกซ์เจอร์ git ที่สร้างจาก tarball, update.channel ที่ไม่ได้คงอยู่, ตำแหน่งบันทึกการติดตั้ง Plugin แบบเดิม, การคงอยู่ของบันทึกการติดตั้งจากมาร์เก็ตเพลสที่หายไป และการย้ายเมทาดาทาการกำหนดค่าระหว่าง plugins update แพ็กเกจ 2026.4.26 ที่เผยแพร่อาจแจ้งเตือนเกี่ยวกับไฟล์ตราประทับเมทาดาทาบิลด์ในเครื่องที่เผยแพร่ไปแล้ว แพ็กเกจที่ใหม่กว่านั้นต้องเป็นไปตามสัญญาแพ็กเกจสมัยใหม่ ช่องว่างเดียวกันเหล่านั้นจะทำให้การตรวจสอบรุ่นล้มเหลว

ใช้โปรไฟล์ Package Acceptance ที่กว้างขึ้นเมื่อคำถามเกี่ยวกับรุ่นเป็นเรื่องของแพ็กเกจที่ติดตั้งได้จริง:

bash

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: ช่องทางตรวจสอบแบบรวดเร็วสำหรับการติดตั้งแพ็กเกจ/ช่องทาง/เอเจนต์ เครือข่าย Gateway และการโหลดการกำหนดค่าใหม่
package: สัญญาการติดตั้ง/อัปเดต/รีสตาร์ต/แพ็กเกจ Plugin พร้อมหลักฐานการติดตั้ง Skills จาก ClawHub แบบใช้งานจริง ซึ่งเป็นค่าเริ่มต้นของการตรวจสอบรุ่นเผยแพร่
product: package พร้อมช่องทาง MCP, การล้าง Cron/เอเจนต์ย่อย, การค้นหาเว็บของ OpenAI และ OpenWebUI
full: ส่วนงานเส้นทางการเผยแพร่ผ่าน Docker พร้อม OpenWebUI
custom: รายการ docker_lanes ที่ระบุอย่างแน่นอนสำหรับการเรียกใช้งานซ้ำแบบเจาะจง

สำหรับหลักฐาน Telegram ของแพ็กเกจตัวเลือก ให้เปิดใช้ telegram_mode=mock-openai หรือ telegram_mode=live-frontier ใน Package Acceptance เวิร์กโฟลว์จะส่งทาร์บอล package-under-test ที่แก้ค่าแล้วไปยังช่องทาง Telegram ส่วนเวิร์กโฟลว์ Telegram แบบสแตนด์อโลนยังคงรับข้อกำหนด npm ที่เผยแพร่แล้วสำหรับการตรวจสอบหลังเผยแพร่

ระบบอัตโนมัติสำหรับเผยแพร่รุ่นปกติ

สำหรับการเผยแพร่รุ่นเบตา, latest, Plugin, GitHub Release และแพลตฟอร์ม OpenClaw Release Publish คือจุดเริ่มต้นปกติที่ทำการเปลี่ยนแปลง เส้นทางรุ่นเสถียรแบบขยายรายเดือน .33+ ที่เผยแพร่เฉพาะ npm ไม่ใช้ตัวประสานงานนี้ เวิร์กโฟลว์ปกติจะประสานเวิร์กโฟลว์ผู้เผยแพร่ที่เชื่อถือได้ตามลำดับที่ รุ่นเผยแพร่ต้องใช้:

เช็กเอาต์แท็กรุ่นเผยแพร่และหาค่า SHA ของคอมมิต
ตรวจสอบว่าสามารถเข้าถึงแท็กได้จาก main หรือ release/* (หรือสาขาอัลฟาของ Tideclaw สำหรับรุ่นก่อนเผยแพร่แบบอัลฟา)
เรียกใช้ pnpm plugins:sync:check
สั่งงาน Plugin NPM Release ด้วย publish_scope=all-publishable และ ref=<release-sha>
สั่งงาน Plugin ClawHub Release ด้วยขอบเขตและ SHA เดียวกัน
สั่งงาน OpenClaw NPM Release ด้วยแท็กรุ่นเผยแพร่, dist-tag ของ npm และ preflight_run_id ที่บันทึกไว้ หลังจากตรวจสอบ full_release_validation_run_id ที่บันทึกไว้และรอบการเรียกใช้ที่ตรงกันทุกประการ
สำหรับรุ่นเสถียร ให้สร้างหรืออัปเดตรุ่นเผยแพร่บน GitHub เป็นฉบับร่าง สั่งงาน Windows Node Release ด้วย windows_node_tag ที่ระบุชัดเจนและ windows_node_installer_digests ที่ผู้สมัครอนุมัติ และตรวจสอบแอสเซ็ตตัวติดตั้ง/ผลรวมตรวจสอบมาตรฐานของ Windows นอกจากนี้ ให้สั่งงาน Android Release เพื่อสร้าง APK ที่ลงนามสำหรับแท็กที่ตรงกันทุกประการ พร้อมผลรวมตรวจสอบและข้อมูลที่มา ตรวจสอบสัญญาแอสเซ็ตเนทีฟทั้งสองก่อนเผยแพร่ฉบับร่าง

ตัวอย่างการเผยแพร่รุ่นเบตา:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

เผยแพร่รุ่นเสถียรไปยัง dist-tag เบตาเริ่มต้น:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

การเลื่อนรุ่นเสถียรไปยัง latest โดยตรงต้องระบุอย่างชัดเจน:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=latest

ใช้เวิร์กโฟลว์ระดับล่าง Plugin NPM Release และ Plugin ClawHub Release เฉพาะสำหรับงานซ่อมแซมหรือเผยแพร่ซ้ำแบบเจาะจงเท่านั้น OpenClaw Release Publish จะปฏิเสธ plugin_publish_scope=selected เมื่อ publish_openclaw_npm=true เพื่อไม่ให้แพ็กเกจแกนหลักเผยแพร่โดยไม่มี Plugin ทางการทั้งหมดที่เผยแพร่ได้ รวมถึง @openclaw/diffs-language-pack สำหรับการซ่อมแซม Plugin ที่เลือก ให้ตั้งค่า publish_openclaw_npm=false พร้อม plugin_publish_scope=selected และ plugins=@openclaw/name หรือสั่งงานเวิร์กโฟลว์ลูกโดยตรง

การบูตสแตรป ClawHub สำหรับการเผยแพร่ครั้งแรกเป็นข้อยกเว้น: ให้สั่งงาน Plugin ClawHub New จาก main ที่เชื่อถือได้ และส่ง SHA เต็มของรุ่นเผยแพร่เป้าหมายผ่าน ref ห้ามเรียกใช้เวิร์กโฟลว์บูตสแตรปเองจากแท็กหรือสาขารุ่นเผยแพร่:

bash

gh workflow run plugin-clawhub-new.yml \  --ref main \  -f plugins=@openclaw/name \  -f ref=<full-40-character-release-sha> \  -f pretag_validation=true \  -f dry_run=true

การตรวจสอบก่อนสร้างแท็กกำหนดให้ dry_run=true ปฏิเสธอินพุตแท็กรุ่นเผยแพร่และการเรียกใช้แม่ และยอมรับเฉพาะเป้าหมายที่ตรงกันทุกประการซึ่งเข้าถึงได้จาก main หรือ release/* กระบวนการนี้จะไม่โหลดข้อมูลประจำตัวของ ClawHub ไม่เผยแพร่ไบต์ของแพ็กเกจ หรือเปลี่ยนแปลง การกำหนดค่าผู้เผยแพร่ที่เชื่อถือได้ เวิร์กโฟลว์ยังคงแก้ค่าแผนรีจิสทรีที่ใช้งานจริง เช็กเอาต์และแพ็กเป้าหมายเฉพาะในงานที่ไม่มีข้อมูลลับ จัดเตรียม ชุดเครื่องมือ ClawHub ที่ล็อกไว้ และตรวจสอบอาร์ติแฟกต์ที่เปลี่ยนแปลงไม่ได้ รวมถึง สลัก/อัตลักษณ์ของแพ็กเกจ ก่อนมีแท็กรุ่นเผยแพร่ อนุมัติสภาพแวดล้อม clawhub-plugin-bootstrap หลังจากงานแพ็กที่ไม่มีข้อมูลลับ เสร็จสิ้นแล้วเท่านั้น งานตรวจสอบที่ได้รับการป้องกันนี้ไม่มีข้อมูลประจำตัวหรือคำสั่งที่ทำการเปลี่ยนแปลง

การทดลองแบบแห้งที่อนุมัติแล้วหรือการบูตสแตรปจริงหลังสร้างแท็กต้องระบุ แท็กรุ่นเผยแพร่ที่ตรงกันทุกประการ รวมถึงรหัสการเรียกใช้ รอบ และ สาขาของ OpenClaw Release Publish แม่ ตัวแม่รับรอง SHA ของเวิร์กโฟลว์ตัวเองและ SHA ของ main ที่เชื่อถือได้ซึ่งตรงกันทุกประการและแยกต่างหากสำหรับ Plugin ClawHub New การเรียกใช้ลูกและการอนุมัติ สภาพแวดล้อมที่ได้รับการป้องกันทุกรายการต้องตรงกับ SHA ของลูกที่อนุมัตินั้น แท็กรุ่นเผยแพร่จะถูก ตรวจสอบซ้ำก่อนความพยายามเผยแพร่และการเปลี่ยนแปลงผู้เผยแพร่ที่เชื่อถือได้ทุกครั้ง

งานแพ็ก อัปโหลดอาร์ติแฟกต์ที่เปลี่ยนแปลงไม่ได้หนึ่งรายการ โดยชื่อ, รหัส/ไดเจสต์อาร์ติแฟกต์ของ Actions, การเรียกใช้/รอบของผู้ผลิต, SHA เป้าหมาย และ SHA-256/ขนาดของทาร์บอลแต่ละแพ็กเกจ จะถูกส่งต่อไปยังงานตรวจสอบและงานที่ได้รับการป้องกัน งานที่ได้รับการป้องกันจะเช็กเอาต์เฉพาะเครื่องมือจาก main ที่เชื่อถือได้ ตรวจสอบทูเพิลของอาร์ติแฟกต์ผ่าน GitHub API ดาวน์โหลด ด้วยรหัสอาร์ติแฟกต์ที่ตรงกันทุกประการ คำนวณแฮชของทุกทาร์บอลใหม่ และตรวจสอบพาธ TAR ภายในเครื่องกับ อัตลักษณ์ของแพ็กเกจตามกฎการทำให้เป็นมาตรฐาน USTAR ของ CLI ที่ปักหมุดไว้ จากนั้นตัวเลือกทุกตัว จะผ่านการทดลองเผยแพร่แบบแห้งของ CLI ที่ปักหมุดไว้ ซึ่งจะส่งคืนก่อน การค้นหารีจิสทรีหรือการยืนยันตัวตน ตัวกรองเบื้องต้นของงานข้อมูลประจำตัวจำกัด ClawPack ที่บีบอัด ไว้ที่ 120 MiB, เพย์โหลดไฟล์รวมที่ 50 MiB, ข้อมูล TAR ที่ขยายแล้วที่ 64 MiB และ จำนวนรายการ TAR ที่ 10,000 การซ่อมแซมผู้เผยแพร่ที่เชื่อถือได้สำหรับแพ็กเกจที่มีอยู่ยังคงเป็น การกำหนดค่าเท่านั้น แต่ยังคงแพ็กเป้าหมายและกำหนดให้แท็กที่ร้องขอ รวมถึงไบต์และข้อมูลเมตาของรีจิสทรีตรงกันทุกประการก่อนเปลี่ยนแปลงการกำหนดค่า ผู้เผยแพร่ที่เชื่อถือได้ การตรวจสอบหลังเผยแพร่จะดาวน์โหลดอาร์ติแฟกต์ ClawHub และ กำหนดให้มี SHA-256 และขนาดเดียวกัน การกู้คืนด้วยการเรียกใช้งานที่ล้มเหลวซ้ำอาจนำอาร์ติแฟกต์แพ็กเกจ จากรอบก่อนหน้ามาใช้ซ้ำได้เฉพาะเมื่อการทำงานของผู้ผลิตที่ตรงกันทุกประการเสร็จสิ้น สำเร็จแล้วเท่านั้น หลักฐานสุดท้ายยังผูกกับเวอร์ชัน ClawHub ที่ล็อกไว้, SHA-256 ของล็อก และค่าความถูกต้องของ npm หากไม่ตรงกัน ต้องใช้แพ็กเกจเวอร์ชันใหม่

อินพุตเวิร์กโฟลว์ NPM

OpenClaw NPM Release รับอินพุตที่ผู้ปฏิบัติงานควบคุมดังต่อไปนี้:

tag: แท็กรุ่นเผยแพร่ที่จำเป็น เช่น v2026.4.2, v2026.4.2-1, v2026.4.2-beta.1 หรือ v2026.4.2-alpha.1; เมื่อ preflight_only=true ค่านี้อาจเป็น SHA คอมมิตเต็ม 40 อักขระปัจจุบันของสาขาเวิร์กโฟลว์สำหรับการตรวจสอบเบื้องต้นเท่านั้นได้ด้วย
preflight_only: true สำหรับการตรวจสอบ/สร้าง/จัดแพ็กเกจเท่านั้น และ false สำหรับเส้นทางเผยแพร่จริง
preflight_run_id: รหัสการเรียกใช้การตรวจสอบเบื้องต้นที่สำเร็จซึ่งมีอยู่แล้ว จำเป็นในเส้นทางเผยแพร่จริง เพื่อให้เวิร์กโฟลว์นำทาร์บอลที่เตรียมไว้กลับมาใช้แทนการสร้างใหม่
full_release_validation_run_id: รหัสการเรียกใช้ Full Release Validation ที่สำเร็จสำหรับแท็ก/SHA นี้ จำเป็นสำหรับการเผยแพร่จริง การเผยแพร่รุ่นเบตาอาจดำเนินการโดยอาศัยเฉพาะการตรวจสอบเบื้องต้นพร้อมคำเตือน แต่การเลื่อนรุ่นเสถียร/latest ยังคงจำเป็นต้องใช้ค่านี้
full_release_validation_run_attempt: รอบการเรียกใช้จำนวนเต็มบวกที่ตรงกันทุกประการซึ่งจับคู่กับ full_release_validation_run_id; จำเป็นทุกครั้งที่ระบุรหัสการเรียกใช้ เพื่อไม่ให้การเรียกใช้ซ้ำเปลี่ยนหลักฐานการอนุญาตระหว่างการเผยแพร่
release_publish_run_id: รหัสการเรียกใช้ OpenClaw Release Publish ที่อนุมัติแล้ว จำเป็นเมื่อเวิร์กโฟลว์นี้ถูกสั่งงานโดยตัวแม่ดังกล่าว (การเรียกเผยแพร่จริงโดยแอ็กเตอร์บอต)
plugin_npm_run_id: รหัสการเรียกใช้ Plugin NPM Release ที่สำเร็จและมีส่วนหัวตรงกันทุกประการ จำเป็นสำหรับการเผยแพร่แพ็กเกจแกนหลัก extended-stable จริง
npm_dist_tag: แท็กเป้าหมาย npm สำหรับเส้นทางเผยแพร่ รับค่า alpha, beta, latest หรือ extended-stable และมีค่าเริ่มต้นเป็น beta แพตช์สุดท้าย 33 ขึ้นไปต้องใช้ extended-stable; โดยค่าเริ่มต้น extended-stable จะปฏิเสธแพตช์ก่อนหน้า และจะปฏิเสธแท็กที่ไม่ใช่แท็กสุดท้ายเสมอ
bypass_extended_stable_guard: บูลีนสำหรับการทดสอบเท่านั้น ค่าเริ่มต้นคือ false; เมื่อใช้กับ npm_dist_tag=extended-stable จะข้ามการตรวจสอบสิทธิ์รุ่นเสถียรแบบขยายรายเดือน ขณะยังคงการตรวจสอบอัตลักษณ์รุ่นเผยแพร่ อาร์ติแฟกต์ การอนุมัติ และการอ่านค่ากลับ

Plugin NPM Release รับ npm_dist_tag=default สำหรับพฤติกรรมรุ่นเผยแพร่ ที่มีอยู่ หรือ npm_dist_tag=extended-stable สำหรับเส้นทางรายเดือนที่มีการป้องกัน ตัวเลือก extended-stable กำหนดให้ publish_scope=all-publishable, อินพุต plugins ว่างเปล่า, แพตช์สุดท้ายตั้งแต่ 33 ขึ้นไป และสาขามาตรฐาน extended-stable/YYYY.M.33 ที่ปลายสาขาตรงกันทุกประการ โดยจะไม่ย้ายแท็ก Plugin latest หรือ beta เวอร์ชันแพ็กเกจใหม่จะได้รับ extended-stable แบบอะตอมมิก ผ่านการเผยแพร่ที่เชื่อถือได้ด้วย OIDC (npm publish --tag extended-stable) เวิร์กโฟลว์ ต้นทางนี้ไม่ใช้ npm dist-tag add ที่ยืนยันตัวตนด้วยโทเค็น การลองใหม่ จะข้ามเวอร์ชันที่ตรงกันทุกประการซึ่งมีอยู่ใน npm แล้ว จากนั้นจะปิดแบบล้มเหลว เว้นแต่ การอ่านค่ากลับอย่างครบถ้วนยืนยันว่าทุกแพ็กเกจที่ตรงกันทุกประการและแท็ก extended-stable สอดคล้องกันแล้ว

OpenClaw Release Publish รับอินพุตที่ผู้ปฏิบัติงานควบคุมดังต่อไปนี้:

tag: แท็กรุ่นเผยแพร่ที่จำเป็น ซึ่งต้องมีอยู่แล้ว
preflight_run_id: รหัสการเรียกใช้การตรวจสอบเบื้องต้นของ OpenClaw NPM Release ที่สำเร็จ จำเป็นเมื่อ publish_openclaw_npm=true หรือ plugin_publish_scope=all-publishable
full_release_validation_run_id: รหัสการเรียกใช้ Full Release Validation ที่สำเร็จ จำเป็นเมื่อ publish_openclaw_npm=true หรือ plugin_publish_scope=all-publishable
full_release_validation_run_attempt: รอบจำนวนเต็มบวกที่ตรงกันทุกประการซึ่งจับคู่กับ full_release_validation_run_id; จำเป็นทุกครั้งที่ระบุรหัสการเรียกใช้
windows_node_tag: แท็กรุ่นเผยแพร่ openclaw/openclaw-windows-node ที่ไม่ใช่รุ่นก่อนเผยแพร่และตรงกันทุกประการ จำเป็นสำหรับการเผยแพร่ OpenClaw รุ่นเสถียร
windows_node_installer_digests: แมป JSON แบบกระชับซึ่งผู้สมัครอนุมัติ โดยแมปชื่อตัวติดตั้ง Windows ปัจจุบันไปยังไดเจสต์ sha256: ที่ปักหมุดไว้ จำเป็นสำหรับการเผยแพร่ OpenClaw รุ่นเสถียร
npm_telegram_run_id: รหัสการเรียกใช้ NPM Telegram Beta E2E ที่สำเร็จซึ่งระบุหรือไม่ก็ได้ เพื่อรวมไว้ในหลักฐานรุ่นเผยแพร่สุดท้าย
npm_dist_tag: แท็กเป้าหมาย npm สำหรับแพ็กเกจ OpenClaw ซึ่งเป็นหนึ่งใน alpha, beta หรือ latest
plugin_publish_scope: มีค่าเริ่มต้นเป็น all-publishable; ใช้ selected เฉพาะสำหรับงานซ่อมแซม Plugin เท่านั้นแบบเจาะจงโดยตั้งค่า publish_openclaw_npm=false
plugins: ชื่อแพ็กเกจ @openclaw/* คั่นด้วยจุลภาค เมื่อ plugin_publish_scope=selected
publish_openclaw_npm: มีค่าเริ่มต้นเป็น true; ตั้งค่าเป็น false เฉพาะเมื่อใช้เวิร์กโฟลว์เป็นตัวประสานงานการซ่อมแซม Plugin เท่านั้น
release_profile: โปรไฟล์ความครอบคลุมของรุ่นเผยแพร่ที่ใช้สำหรับสรุปหลักฐานรุ่นเผยแพร่ ค่าเริ่มต้นคือ from-validation ซึ่งอ่านค่าจากแมนิเฟสต์การตรวจสอบ หรือเขียนทับด้วย beta, stable หรือ full
wait_for_clawhub: มีค่าเริ่มต้นเป็น false เพื่อไม่ให้ความพร้อมใช้งานของ npm ถูกขัดขวางโดยไซด์คาร์ ClawHub; ตั้งค่าเป็น true เฉพาะเมื่อการเสร็จสิ้นของเวิร์กโฟลว์ต้องรวมการเสร็จสิ้นของ ClawHub

OpenClaw Release Checks รับอินพุตที่ผู้ปฏิบัติงานควบคุมดังต่อไปนี้:

ref: สาขา แท็ก หรือ SHA คอมมิตเต็มที่จะตรวจสอบ การตรวจสอบที่มีข้อมูลลับกำหนดให้คอมมิตที่แก้ค่าแล้วเข้าถึงได้จากสาขาหรือแท็กรุ่นเผยแพร่ของ OpenClaw
run_release_soak: เลือกใช้การทดสอบแช่แบบใช้งานจริง/E2E อย่างละเอียด เส้นทางรุ่นเผยแพร่ผ่าน Docker และผู้รอดจากการอัปเกรดทุกเวอร์ชันนับจากจุดเริ่มต้น สำหรับการตรวจสอบรุ่นเบตา ค่านี้จะถูกบังคับให้เปิดโดย release_profile=stable และ release_profile=full

กฎ:

เวอร์ชันสมบูรณ์และเวอร์ชันแก้ไขทั่วไปที่มีเลขแพตช์ต่ำกว่า 33 สามารถเผยแพร่ไปยัง beta หรือ latest ได้ ส่วนเวอร์ชันสมบูรณ์ที่มีเลขแพตช์ 33 ขึ้นไปต้องเผยแพร่ไปยัง extended-stable และระบบจะปฏิเสธเวอร์ชันที่มีคำต่อท้ายสำหรับการแก้ไข ณ ขอบเขตดังกล่าว
แท็กก่อนเผยแพร่รุ่นเบตาสามารถเผยแพร่ไปยัง beta เท่านั้น ส่วนแท็กก่อนเผยแพร่รุ่นแอลฟาสามารถเผยแพร่ไปยัง alpha เท่านั้น
สำหรับ OpenClaw NPM Release อนุญาตให้ป้อน SHA แบบเต็มของคอมมิตได้เฉพาะเมื่อ preflight_only=true
OpenClaw Release Checks และ Full Release Validation ใช้สำหรับการตรวจสอบความถูกต้องเท่านั้นเสมอ
เส้นทางการเผยแพร่จริงต้องใช้ npm_dist_tag เดียวกับที่ใช้ระหว่างการตรวจสอบล่วงหน้า เวิร์กโฟลว์จะตรวจสอบข้อมูลเมตาดังกล่าวก่อนดำเนินการเผยแพร่ต่อ

ลำดับการเผยแพร่รุ่นเสถียรแบบเบตา/ล่าสุดตามปกติ

ลำดับแบบเดิมนี้ใช้สำหรับการเผยแพร่ตามปกติที่มีการประสานงาน ซึ่งครอบคลุม Plugin, GitHub Release, Windows และงานสำหรับแพลตฟอร์มอื่นด้วย ไม่ใช่เส้นทาง extended-stable รายเดือนแบบ .33+ ที่เผยแพร่เฉพาะ npm ซึ่งระบุไว้ด้านบนของหน้านี้

เมื่อจัดทำรุ่นเสถียรแบบประสานงานตามปกติ:

เรียกใช้ OpenClaw NPM Release โดยตั้งค่า preflight_only=true ก่อนมีแท็ก คุณสามารถใช้ SHA แบบเต็มของคอมมิตปัจจุบันในสาขาเวิร์กโฟลว์ เพื่อทดลองรันแบบไม่เผยแพร่ซึ่งใช้ตรวจสอบความถูกต้องของเวิร์กโฟลว์ตรวจสอบล่วงหน้าเท่านั้น
เลือก npm_dist_tag=beta สำหรับขั้นตอนปกติที่เผยแพร่เบตาก่อน หรือเลือก latest เฉพาะเมื่อคุณตั้งใจเผยแพร่รุ่นเสถียรโดยตรง
เรียกใช้ Full Release Validation บนสาขาการเผยแพร่ แท็กการเผยแพร่ หรือ SHA แบบเต็มของคอมมิต เมื่อต้องการ CI ตามปกติพร้อมการครอบคลุมแคชพรอมต์แบบสด, Docker, QA Lab, Matrix และ Telegram จากเวิร์กโฟลว์ที่เรียกใช้ด้วยตนเองเพียงรายการเดียว หากตั้งใจต้องการเพียงกราฟการทดสอบปกติแบบกำหนดผลลัพธ์แน่นอน ให้เรียกใช้เวิร์กโฟลว์ CI ด้วยตนเองบนการอ้างอิงรุ่นที่เผยแพร่แทน
เลือกแท็กการเผยแพร่ openclaw/openclaw-windows-node ที่ไม่ใช่รุ่นก่อนเผยแพร่ให้ตรงกับตัวติดตั้ง x64 และ ARM64 ที่ลงนามแล้วซึ่งควรจัดส่ง บันทึกเป็น windows_node_tag และบันทึกแผนผังไดเจสต์ที่ตรวจสอบความถูกต้องแล้วของตัวติดตั้งเหล่านั้นเป็น windows_node_installer_digests ตัวช่วยสำหรับรุ่นผู้สมัครจะบันทึกทั้งสองค่าและรวมไว้ในคำสั่งเผยแพร่ที่สร้างขึ้น
บันทึก preflight_run_id, full_release_validation_run_id และ full_release_validation_run_attempt ที่ตรงกันจากการเรียกใช้ที่สำเร็จ
เรียกใช้ OpenClaw Release Publish จาก main ที่เชื่อถือได้ โดยใช้ tag เดิม, npm_dist_tag เดิม, windows_node_tag ที่เลือก, windows_node_installer_digests ที่บันทึกไว้ของแท็กนั้น, preflight_run_id, full_release_validation_run_id และ full_release_validation_run_attempt ที่บันทึกไว้ กระบวนการนี้จะเผยแพร่ Plugin ที่แยกออกมาไปยัง npm และ ClawHub ก่อนเลื่อนระดับแพ็กเกจ OpenClaw บน npm
หากรุ่นเผยแพร่อยู่บน beta ให้ใช้เวิร์กโฟลว์ openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml เพื่อเลื่อนระดับเวอร์ชันเสถียรนั้นจาก beta ไปยัง latest
หากตั้งใจเผยแพร่รุ่นโดยตรงไปยัง latest และต้องการให้ beta ใช้บิลด์เสถียรเดียวกันทันที ให้ใช้เวิร์กโฟลว์การเผยแพร่เดียวกันเพื่อชี้ dist-tag ทั้งสองไปยังเวอร์ชันเสถียร หรือปล่อยให้การซิงค์ซ่อมแซมตัวเองตามกำหนดการย้าย beta ในภายหลัง

การเปลี่ยนแปลง dist-tag อยู่ในรีโพซิทอรีบัญชีแยกประเภทการเผยแพร่ เนื่องจากยังต้องใช้ NPM_TOKEN ขณะที่รีโพซิทอรีซอร์สใช้การเผยแพร่ผ่าน OIDC เท่านั้น วิธีนี้ทำให้ทั้งเส้นทางการเผยแพร่โดยตรงและเส้นทางการเลื่อนระดับที่เผยแพร่เบตาก่อนได้รับการบันทึกไว้ในเอกสารและมองเห็นได้สำหรับผู้ปฏิบัติงาน

หากผู้ดูแลจำเป็นต้องเปลี่ยนไปใช้การยืนยันตัวตน npm ภายในเครื่อง ให้เรียกใช้คำสั่ง CLI ของ 1Password (op) เฉพาะภายในเซสชัน tmux ที่จัดไว้โดยเฉพาะเท่านั้น อย่าเรียก op โดยตรงจากเชลล์หลักของเอเจนต์ การเก็บไว้ภายใน tmux ทำให้สามารถสังเกตพรอมต์ การแจ้งเตือน และการจัดการ OTP ได้ และป้องกันการแจ้งเตือนซ้ำบนโฮสต์

เอกสารอ้างอิงสาธารณะ

ผู้ดูแลใช้เอกสารการเผยแพร่แบบส่วนตัวใน openclaw/maintainers/release/README.md เป็นคู่มือการดำเนินงานจริง

เนื้อหาที่เกี่ยวข้อง

ช่องทางการเผยแพร่

Was this useful?

นโยบายการเผยแพร่

การตั้งชื่อเวอร์ชัน

รอบการรีลีส

การเผยแพร่ extended-stable รายเดือนเฉพาะ npm

รายการตรวจสอบสำหรับผู้ดำเนินการรีลีสปกติ

ปิดงาน `main` สำหรับรุ่นเสถียร

การตรวจสอบเบื้องต้นก่อนออกรุ่น

กล่องทดสอบรีลีส

Vitest

Docker

QA Lab

แพ็กเกจ

ระบบอัตโนมัติสำหรับเผยแพร่รุ่นปกติ

อินพุตเวิร์กโฟลว์ NPM

ลำดับการเผยแพร่รุ่นเสถียรแบบเบตา/ล่าสุดตามปกติ

เอกสารอ้างอิงสาธารณะ

เนื้อหาที่เกี่ยวข้อง

On this page

Molty

การตั้งชื่อเวอร์ชัน

รอบการรีลีส

การเผยแพร่ extended-stable รายเดือนเฉพาะ npm

รายการตรวจสอบสำหรับผู้ดำเนินการรีลีสปกติ

ปิดงาน main สำหรับรุ่นเสถียร

การตรวจสอบเบื้องต้นก่อนออกรุ่น

กล่องทดสอบรีลีส

Vitest

Docker

QA Lab

แพ็กเกจ

ระบบอัตโนมัติสำหรับเผยแพร่รุ่นปกติ

อินพุตเวิร์กโฟลว์ NPM

ลำดับการเผยแพร่รุ่นเสถียรแบบเบตา/ล่าสุดตามปกติ

เอกสารอ้างอิงสาธารณะ

เนื้อหาที่เกี่ยวข้อง

On this page

ปิดงาน `main` สำหรับรุ่นเสถียร