OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Release and CI

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

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

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

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

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

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

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

รอบการเผยแพร่

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

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

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

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

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

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 และจะถูกบันทึกในสรุปเวิร์กโฟลว์ การข้ามนี้ ไม่ข้าม ref เวิร์กโฟลว์ extended-stable/YYYY.M.33 มาตรฐาน ความเท่ากันของปลายสาขา/แท็ก/เช็กเอาต์ ไวยากรณ์แท็ก final ความเท่ากันของเวอร์ชัน แพ็กเกจ/แท็ก อัตลักษณ์ของการรันและแมนิเฟสต์ที่อ้างอิง ที่มาของ tarball การอนุมัติสภาพแวดล้อม การอ่านกลับจากรีจิสทรี หรือหลักฐานการซ่อมแซมตัวเลือก

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

bash
npm view [email protected] version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

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

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

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

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

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

  1. เริ่มจาก main ปัจจุบัน: ดึงข้อมูลล่าสุด ยืนยันว่าคอมมิตเป้าหมายถูกพุชแล้ว และยืนยันว่าไปป์ไลน์ CI ของ main ผ่านมากพอที่จะสร้างสาขาได้

  2. สร้าง release/YYYY.M.PATCH จากคอมมิตนั้น การแบ็กพอร์ตเป็นทางเลือก; ใช้เฉพาะชุดที่ผู้ดำเนินการเลือก เพิ่มเวอร์ชันในทุกตำแหน่งที่กำหนด รัน pnpm release:prep ดำเนินการแก้ไขรุ่นเผยแพร่และฟอร์เวิร์ดพอร์ตที่จำเป็นให้เสร็จสิ้น และตรวจสอบ src/plugins/compat/registry.ts รวมถึง src/commands/doctor/shared/deprecation-compat.ts

  3. ตรึงคอมมิตก่อนบันทึกการเปลี่ยนแปลงที่ผลิตภัณฑ์เสร็จสมบูรณ์เป็น Code SHA รันการตรวจสอบล่วงหน้าของซอร์สแบบกำหนดผลลัพธ์แน่นอน จากนั้นใช้ node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH ขั้นตอนนี้จะตรึงเครื่องมือเวิร์กโฟลว์ที่เชื่อถือได้ ขณะที่เมทริกซ์ Vitest, Docker, QA, แพ็กเกจ และประสิทธิภาพฉบับเต็มกำหนดเป้าหมายไปยัง Code SHA ที่ตรงกันทุกประการ

  4. จำแนกความล้มเหลวก่อนแก้ไข ความล้มเหลวของผลิตภัณฑ์/โค้ดจะสร้าง Code SHA ใหม่และกำหนดให้มีการตรวจสอบฉบับเต็มที่ผ่านสำหรับ SHA นั้น ความล้มเหลวของเวิร์กโฟลว์ ชุดทดสอบ ข้อมูลประจำตัว การอนุมัติ หรือโครงสร้างพื้นฐานจะได้รับการซ่อมแซมในพื้นผิวที่เป็นเจ้าของและรันใหม่กับ Code SHA เดิม

  5. หลังจาก Code SHA ผ่านแล้วเท่านั้น ให้สร้างส่วนบนสุดของ CHANGELOG.md จาก pull request ที่ผสานแล้วและคอมมิตโดยตรงนับจากแท็กรุ่นที่จัดส่งแล้วล่าสุดซึ่งเข้าถึงได้ ทำให้รายการมุ่งเน้นผู้ใช้และไม่ซ้ำกัน เมื่อแท็กรุ่นที่จัดส่งแล้วซึ่งแยกสายออกไปหรือฟอร์เวิร์ดพอร์ตในภายหลังเชื่อมโยง pull request ที่เผยแพร่แล้วใหม่อีกครั้ง ให้ส่งแท็กนั้นอย่างชัดเจนเป็น --shipped-ref

  6. คอมมิตเฉพาะ CHANGELOG.md คอมมิตนี้คือ Release SHA diff ทั้งหมดจาก Code SHA ถึง Release SHA ต้องเป็น CHANGELOG.md เท่านั้น; เส้นทางอื่นที่เปลี่ยนแปลงจะทำให้การเผยแพร่ย้อนกลับไปยังขั้นตอนที่ 2

  7. รัน Full Release Validation แบบตรึง SHA สำหรับ Release SHA โดยเปิดใช้การนำหลักฐานกลับมาใช้ โพรเซสหลักแบบเบาต้องบันทึก changelog-only-release-v1 ชี้ไปยัง Code SHA ที่ผ่าน และไม่ส่งเลนย่อยของผลิตภัณฑ์ใด ๆ ขั้นตอนนี้นำหลักฐานผลิตภัณฑ์กลับมาใช้; ไม่ได้นำไบต์ของแพ็กเกจกลับมาใช้

  8. รัน OpenClaw NPM Release พร้อม preflight_only=true กับ Release SHA/แท็ก บันทึก preflight_run_id ที่สำเร็จ ขั้นตอนนี้จะสร้างและตรวจสอบไบต์แพ็กเกจที่ตรงกันทุกประการซึ่งรวมบันทึกการเปลี่ยนแปลงฉบับสุดท้าย

  9. แท็ก Release SHA จากนั้นรันตัวช่วยสำหรับรุ่นที่พร้อมเสนอด้วยโพรเซสหลักการตรวจสอบ Release-SHA ที่สำเร็จและการตรวจสอบล่วงหน้าของ npm แทนการส่งทั้งสองรายการอีกครั้ง:

    bash
    pnpm release:candidate -- \  --tag vYYYY.M.PATCH-beta.N \  --full-release-run <release-sha-validation-run-id> \  --npm-preflight-run <preflight-run-id> \  --skip-dispatch

    สำหรับรุ่นเสถียร ให้ส่ง --windows-node-tag vX.Y.Z ด้วย ตัวช่วยจะตรวจสอบแหล่งที่มาของบันทึกประจำรุ่น ไบต์พรีไฟลต์ของ npm หลักฐานการติดตั้ง/อัปเดต Parallels หลักฐานแพ็กเกจ Telegram และแผนการเผยแพร่ plugin จากนั้นจะแสดงคำสั่งเผยแพร่

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

    จากนั้นเรียกใช้การทดสอบยอมรับแพ็กเกจหลังเผยแพร่กับแพ็กเกจ [email protected] หรือ openclaw@beta ที่เผยแพร่แล้ว หากรุ่นก่อนเผยแพร่ที่พุชหรือเผยแพร่แล้วต้องแก้ไข ให้สร้างหมายเลขรุ่นก่อนเผยแพร่ลำดับถัดไปที่ตรงกัน ห้ามลบหรือเขียนทับรุ่นเก่า

  10. เมื่อความพยายามเผยแพร่ล้มเหลว ให้คง Release SHA ไว้โดยไม่เปลี่ยนแปลง เว้นแต่ความล้มเหลวจะพิสูจน์ว่าผลิตภัณฑ์หรือบันทึกการเปลี่ยนแปลงมีข้อบกพร่อง ให้ดำเนินการต่อจากโปรเซสย่อยและอาร์ติแฟกต์ที่เปลี่ยนแปลงไม่ได้ซึ่งสำเร็จแล้ว ห้ามสร้างใหม่หรือเผยแพร่ซ้ำแพ็กเกจเวอร์ชันที่สำเร็จแล้ว

  11. สำหรับรุ่นเสถียร ให้ดำเนินการต่อเฉพาะเมื่อเบตาหรือรุ่นทดสอบก่อนออกรุ่นที่ผ่านการตรวจสอบแล้วมีหลักฐานการตรวจสอบที่จำเป็น การเผยแพร่รุ่นเสถียรไปยัง 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 release ของ OpenClaw ส่งแท็กออกรุ่น openclaw/openclaw-windows-node ที่ลงนามแล้วแบบตรงกันทุกประการเป็น windows_node_tag และส่งแผนที่ไดเจสต์ของตัวติดตั้งที่ผู้สมัครอนุมัติแล้วเป็น windows_node_installer_digests; OpenClaw Release Publish จะคงฉบับร่างของรุ่นไว้ ส่ง Windows Node Release และตรวจสอบแอสเซ็ตทั้งสามก่อนเผยแพร่

  12. หลังเผยแพร่ ให้เรียกใช้ตัวตรวจสอบหลังเผยแพร่ของ npm, E2E Telegram แบบสแตนด์อโลนบน npm ที่เผยแพร่แล้วซึ่งเป็นทางเลือกเมื่อจำเป็นต้องมีหลักฐานช่องทางหลังเผยแพร่, การโปรโมต dist-tag เมื่อจำเป็น, ตรวจสอบหน้า GitHub release ที่สร้างขึ้น, ดำเนินขั้นตอนประกาศออกรุ่น แล้วจึงทำ การปิดงาน main สำหรับรุ่นเสถียร ให้เสร็จสิ้นก่อนถือว่าการออกรุ่นเสถียรเสร็จสมบูรณ์

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

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

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

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

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

หากพาเรนต์ Release Publish ล้มเหลวเฉพาะหลังจากแนบหลักฐาน npm/plugin ที่เปลี่ยนแปลงไม่ได้แล้ว ให้ซ่อมแซมและเผยแพร่แอสเซ็ตแพลตฟอร์มรุ่นเสถียรทุกประเภทก่อน จากนั้นผู้ดูแลอาจส่งการปิดงานด้วยตนเองโดยใช้ allow_failed_publish_recovery=true; โหมดดังกล่าวยอมรับเฉพาะพาเรนต์ที่ล้มเหลวและเสร็จสิ้นแล้ว และยังต้องมีสัญญาแอสเซ็ต Android และ Windows แบบตรงกันทุกประการ ไดเจสต์ SHA-256 ของ GitHub การตรวจสอบผลรวมตรวจสอบ แหล่งที่มาของ Android และการโปรโมต Windows ที่พาเรนต์ส่งและสำเร็จ ซึ่งการตรวจสอบ Authenticode และไดเจสต์ที่ผู้สมัครอนุมัติตรงกับตัวติดตั้งที่เผยแพร่ ควบคู่กับการตรวจสอบ macOS/appcast ตามปกติ การปิดงานอัตโนมัติจากการพุชจะไม่เปิดใช้โหมดกู้คืนนี้

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

พรีไฟลต์การออกรุ่น

  • เรียกใช้ pnpm check:test-types ก่อนพรีไฟลต์การออกรุ่น เพื่อให้ TypeScript สำหรับการทดสอบยังได้รับการครอบคลุมนอกเกต pnpm check ภายในเครื่องที่รวดเร็วกว่า

  • เรียกใช้ pnpm check:architecture ก่อนพรีไฟลต์การออกรุ่น เพื่อให้การตรวจสอบวงจรการนำเข้าและขอบเขตสถาปัตยกรรมที่กว้างขึ้นผ่านทั้งหมดนอกเกตภายในเครื่องที่รวดเร็วกว่า

  • เรียกใช้ pnpm build && pnpm ui:build ก่อน pnpm release:check เพื่อให้อาร์ติแฟกต์รุ่น dist/* ที่คาดไว้และบันเดิล Control UI มีอยู่สำหรับขั้นตอนตรวจสอบแพ็ก

  • เรียกใช้ pnpm release:prep หลังเพิ่มเวอร์ชันรูทและก่อนติดแท็ก โดยจะเรียกใช้ตัวสร้างรุ่นแบบกำหนดแน่นอนทุกตัวที่มักคลาดเคลื่อนหลังการเปลี่ยนเวอร์ชัน/การกำหนดค่า/API ได้แก่ เวอร์ชัน plugin, shrinkwrap ของ npm, บัญชีรายการ plugin, สคีมาการกำหนดค่าพื้นฐาน, ข้อมูลเมตาการกำหนดค่าช่องทางที่รวมมาให้, เส้นฐานเอกสารการกำหนดค่า, การส่งออก SDK ของ plugin, แมนิเฟสต์สัญญา API ของ SDK สำหรับ Plugin และบันเดิลภาษาของ Control UI นอกจากนี้ยังบล็อกจนกว่าคำแปลแอปเนทีฟและทรัพยากรภาษาที่แพลตฟอร์มสร้างจะตรงกับบัญชีรายการต้นฉบับ หากล่าช้า ให้รอหรือส่ง Native App Locale Refresh ก่อนตรึง Code SHA 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 Lab, Matrix และเลน Telegram รันเสถียรและรันเต็มจะรวมการทดสอบเฝ้าดูเส้นทางการออกรุ่นแบบ live/E2E และ Docker อย่างละเอียดเสมอ โดยเก็บ run_release_soak=true ไว้สำหรับการทดสอบเฝ้าดูเบตาโดยชัดเจน การยอมรับแพ็กเกจมี E2E Telegram สำหรับแพ็กเกจที่เป็นมาตรฐานระหว่างการตรวจสอบผู้สมัคร จึงหลีกเลี่ยงตัวโพลแบบ live ตัวที่สองซึ่งทำงานพร้อมกัน

    ระบุ release_package_spec หลังเผยแพร่เบตาเพื่อนำแพ็กเกจ npm ที่เผยแพร่แล้วกลับมาใช้ในการตรวจสอบรุ่น การยอมรับแพ็กเกจ และ E2E Telegram สำหรับแพ็กเกจ โดยไม่สร้างทาร์บอลล์รุ่นใหม่ ระบุ npm_telegram_package_spec เฉพาะเมื่อ Telegram ควรใช้แพ็กเกจที่เผยแพร่ซึ่งต่างจากส่วนอื่นของการตรวจสอบรุ่น ระบุ package_acceptance_package_spec เมื่อการยอมรับแพ็กเกจควรใช้แพ็กเกจที่เผยแพร่ซึ่งต่างจากข้อกำหนดแพ็กเกจรุ่น ระบุ evidence_package_spec เมื่อรายงานหลักฐานรุ่นควรพิสูจน์ว่าการตรวจสอบตรงกับแพ็กเกจ npm ที่เผยแพร่ โดยไม่บังคับใช้ E2E Telegram

    bash
    node scripts/full-release-validation-at-sha.mjs \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

  • เรียกใช้เวิร์กโฟลว์ Package Acceptance แบบแมนนวลเมื่อต้องการหลักฐานจากช่องทางเสริมสำหรับแพ็กเกจที่เป็นตัวเลือก ระหว่างที่งานรีลีสดำเนินต่อไป ใช้ source=npm สำหรับ openclaw@beta, openclaw@latest หรือเวอร์ชันรีลีสที่ระบุแน่นอน; ใช้ source=ref เพื่อแพ็ก branch/tag/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 นำตัวจัดกำหนดการรีลีส Docker E2E มาใช้ซ้ำกับ tarball นั้น และสามารถเรียกใช้ QA ของ Telegram กับ tarball เดียวกันโดยใช้ telegram_mode=mock-openai หรือ telegram_mode=live-frontier เมื่อเลน Docker ที่เลือกมี published-upgrade-survivor อาร์ติแฟกต์แพ็กเกจจะเป็นตัวเลือก และ published_upgrade_survivor_baseline จะเลือก 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 [email protected] -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 แบบแมนนวลจะข้ามการจำกัดขอบเขตตามการเปลี่ยนแปลง และบังคับใช้ shard ของ Linux Node, shard ของ Plugin ที่รวมมาด้วย, shard สัญญาของ Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, check-*, check-additional-*, การตรวจสอบเบื้องต้นของอาร์ติแฟกต์ที่สร้างแล้ว, การตรวจสอบเอกสาร, Skills ของ Python, Windows, macOS และเลน i18n ของ Control UI การรัน 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-lab ผ่านตัวรับ OTLP/HTTP ภายในเครื่อง และตรวจสอบการส่งออก trace, metric และ log รวมถึงแอตทริบิวต์ trace ที่มีขอบเขตจำกัดและการปกปิดเนื้อหา/ตัวระบุ โดยไม่ต้องใช้ Opik, Langfuse หรือตัวรวบรวมภายนอกอื่น

  • เรียกใช้ pnpm qa:otel:collector-smoke เมื่อตรวจสอบความเข้ากันได้กับตัวรวบรวม โดยจะกำหนดเส้นทางการส่งออก OTLP ของ QA-lab เดียวกันผ่านคอนเทนเนอร์ Docker ของ OpenTelemetry Collector จริง ก่อนตรวจสอบกับตัวรับภายในเครื่อง

  • เรียกใช้ pnpm qa:prometheus:smoke เมื่อตรวจสอบการ scrape Prometheus ที่มีการป้องกัน โดยจะทดสอบ QA-lab ปฏิเสธการ scrape ที่ไม่ได้ยืนยันตัวตน และตรวจสอบว่ากลุ่ม metric ที่สำคัญต่อรีลีสไม่มีเนื้อหา prompt, ตัวระบุดิบ, โทเค็นการยืนยันตัวตน และพาธภายในเครื่อง

  • เรียกใช้ pnpm qa:observability:smoke สำหรับเลนตรวจสอบเบื้องต้นของ OpenTelemetry และ Prometheus จาก source checkout ต่อเนื่องกัน

  • เรียกใช้ pnpm release:check ก่อนทุกรีลีสที่มีแท็ก

  • ขั้นตอนตรวจสอบเบื้องต้นของ OpenClaw NPM Release จะสร้างหลักฐานรีลีสของ dependency ก่อนแพ็ก npm tarball เกตช่องโหว่จากคำแนะนำด้านความปลอดภัยของ npm จะบล็อกรีลีส รายงานความเสี่ยงของ manifest แบบส่งต่อ, ขอบเขตความเป็นเจ้าของ/การติดตั้ง dependency และการเปลี่ยนแปลง dependency ใช้เป็นหลักฐานรีลีสเท่านั้น รายงานการเปลี่ยนแปลง dependency จะเปรียบเทียบตัวเลือกรีลีสกับแท็กรีลีสก่อนหน้าที่ยังเข้าถึงได้ ขั้นตอนตรวจสอบเบื้องต้นจะอัปโหลดหลักฐาน dependency เป็น openclaw-release-dependency-evidence-<tag> และฝังไว้ภายใต้ dependency-evidence/ ภายในอาร์ติแฟกต์ตรวจสอบเบื้องต้นของ npm ที่เตรียมไว้ด้วย เส้นทางเผยแพร่จริงจะนำอาร์ติแฟกต์ตรวจสอบเบื้องต้นนั้นมาใช้ซ้ำ แล้วแนบหลักฐานเดียวกันกับรีลีส GitHub เป็น openclaw-<version>-dependency-evidence.zip

  • เรียกใช้ OpenClaw Release Publish สำหรับลำดับการเผยแพร่ที่แก้ไขสถานะ หลังจากมีแท็กแล้ว ให้สั่งเผยแพร่ beta และ stable ตามปกติจาก main ที่เชื่อถือได้ โดยแท็กรีลีสยังคงเลือก commit เป้าหมายที่แน่นอนและอาจชี้เข้าไปใน release/YYYY.M.PATCH การเผยแพร่ alpha ของ Tideclaw ยังคงอยู่บน branch alpha ที่ตรงกัน ส่ง preflight_run_id ของ npm สำหรับ OpenClaw ที่สำเร็จ, full_release_validation_run_id ที่สำเร็จ และ full_release_validation_run_attempt ที่แน่นอน และคงขอบเขตการเผยแพร่ Plugin เริ่มต้นเป็น all-publishable เว้นแต่กำลังดำเนินการซ่อมแซมแบบเจาะจงโดยตั้งใจ เวิร์กโฟลว์จะเรียงลำดับการเผยแพร่ npm ของ Plugin, การเผยแพร่ Plugin ไปยัง ClawHub และการเผยแพร่ npm ของ OpenClaw เพื่อไม่ให้เผยแพร่แพ็กเกจหลักก่อน Plugin ที่แยกออกมาเป็นภายนอก ส่วนการโปรโมต Windows และ Android จะทำงานพร้อมกับการเผยแพร่ npm หลักโดยอ้างอิงหน้ารีลีสฉบับร่าง การรันเผยแพร่ซ้ำสามารถทำต่อจากเดิมได้: เวอร์ชัน npm หลักที่เผยแพร่แล้วจะข้ามการสั่งรันส่วนหลัก หลังจากเวิร์กโฟลว์พิสูจน์ว่า tarball ในรีจิสทรีตรงกับอาร์ติแฟกต์ตรวจสอบเบื้องต้นของแท็ก และจะข้ามการโปรโมต Windows/Android เมื่อรีลีสมีสัญญาอาร์ติแฟกต์ที่ตรวจสอบแล้ว ดังนั้นการลองใหม่จะทำซ้ำเฉพาะขั้นตอนที่ล้มเหลว การซ่อมแซมเฉพาะ Plugin แบบเจาะจงต้องใช้ plugin_publish_scope=selected และรายการ Plugin ที่ไม่ว่าง การรัน all-publishable แบบเฉพาะ Plugin ต้องมีหลักฐานการตรวจสอบเบื้องต้นและ Full Release Validation ที่ครบถ้วนและเปลี่ยนแปลงไม่ได้ โดยจะปฏิเสธหลักฐานที่ไม่ครบถ้วน

  • OpenClaw Release Publish แบบ stable ต้องใช้ windows_node_tag ที่แน่นอน หลังจากมีรีลีส openclaw/openclaw-windows-node ที่ตรงกันและไม่ใช่ prerelease แล้ว พร้อมกับแผนที่ windows_node_installer_digests ที่ตัวเลือกได้รับการอนุมัติ ก่อนสั่งรันส่วนการเผยแพร่ใด ๆ ระบบจะตรวจสอบว่ารีลีสต้นทางนั้นเผยแพร่แล้ว ไม่ใช่ prerelease มีตัวติดตั้ง x64/ARM64 ที่จำเป็น และยังคงตรงกับแผนที่ที่อนุมัติ จากนั้นจะสั่งรัน Windows Node Release ขณะที่รีลีส OpenClaw ยังเป็นฉบับร่าง โดยส่งแผนที่ digest ของตัวติดตั้งที่ตรึงไว้โดยไม่เปลี่ยนแปลง เวิร์กโฟลว์ลูกจะดาวน์โหลดตัวติดตั้ง Windows Hub ที่ลงนามแล้วจากแท็กที่ระบุแน่นอนนั้น เปรียบเทียบกับ digest ที่ตรึงไว้ ตรวจสอบบน runner ของ Windows ว่าลายเซ็น Authenticode ใช้ผู้ลงนาม OpenClaw Foundation ตามที่คาดไว้ เขียน manifest SHA-256 และอัปโหลดตัวติดตั้งพร้อม manifest ไปยังรีลีส GitHub มาตรฐานของ OpenClaw จากนั้นดาวน์โหลดอาร์ติแฟกต์ที่โปรโมตแล้วอีกครั้งและตรวจสอบการเป็นสมาชิกใน manifest พร้อมแฮช เวิร์กโฟลว์แม่จะตรวจสอบสัญญาอาร์ติแฟกต์ x64, ARM64 และ checksum ปัจจุบันก่อนเผยแพร่ การกู้คืนโดยตรงจะปฏิเสธชื่ออาร์ติแฟกต์ OpenClawCompanion-* ที่ไม่คาดหมาย ก่อนแทนที่อาร์ติแฟกต์ตามสัญญาที่คาดไว้ด้วยไบต์จากต้นทางที่ตรึงไว้

    สั่งรัน Windows Node Release แบบแมนนวลเฉพาะเพื่อการกู้คืนเท่านั้น และส่งแท็กที่ระบุแน่นอนเสมอ ห้ามใช้ latest พร้อมกับแผนที่ JSON expected_installer_digests ที่ระบุอย่างชัดเจนจากรีลีสต้นทางที่ได้รับอนุมัติ ลิงก์ดาวน์โหลดบนเว็บไซต์ควรชี้ไปยัง URL อาร์ติแฟกต์ของรีลีส OpenClaw ที่ระบุแน่นอนสำหรับรีลีส stable ปัจจุบัน หรือใช้ releases/latest/download/... เฉพาะหลังจากตรวจสอบแล้วว่าการเปลี่ยนเส้นทาง latest ของ GitHub ชี้ไปยังรีลีสเดียวกัน ห้ามลิงก์เฉพาะไปยังหน้ารีลีสของ repo คู่กัน

  • ขณะนี้การตรวจสอบรีลีสทำงานในเวิร์กโฟลว์แบบเรียกใช้ด้วยตนเองที่แยกต่างหาก: OpenClaw Release Checks นอกจากนี้ยังเรียกใช้เลนตรวจสอบความสอดคล้องของม็อก QA Lab รวมถึงโปรไฟล์รีลีส Matrix และเลน QA ของ Telegram ก่อนอนุมัติรีลีส เลนแบบสดใช้สภาพแวดล้อม qa-live-shared; Telegram ยังใช้การเช่าข้อมูลรับรอง Convex CI ด้วย เรียกใช้เวิร์กโฟลว์ QA-Lab - All Lanes แบบเรียกใช้ด้วยตนเองพร้อม matrix_profile=all เมื่อต้องการทุกสถานการณ์ Matrix ที่ยังได้รับการดูแล โดยเวิร์กโฟลว์จะกระจายตัวเลือกนั้นไปยังโปรไฟล์การขนส่ง สื่อ และ E2EE เพื่อให้หลักฐานทั้งหมดเสร็จสิ้นภายในเวลาหมดเวลาของแต่ละงาน

  • การตรวจสอบรันไทม์สำหรับการติดตั้งและอัปเกรดข้ามระบบปฏิบัติการเป็นส่วนหนึ่งของ OpenClaw Release Checks และ Full Release Validation สาธารณะ ซึ่งเรียกเวิร์กโฟลว์แบบนำกลับมาใช้ใหม่ .github/workflows/openclaw-cross-os-release-checks-reusable.yml โดยตรง การแยกนี้เป็นไปโดยเจตนา เพื่อให้เส้นทางรีลีส npm จริงสั้น ทำงานแบบกำหนดผลลัพธ์ได้ และมุ่งเน้นอาร์ติแฟกต์ ขณะที่การตรวจสอบแบบสดที่ช้ากว่าจะอยู่ในเลนของตนเอง เพื่อไม่ให้การเผยแพร่หยุดชะงักหรือถูกบล็อก

  • ควรสั่งให้การตรวจสอบรีลีสที่มีข้อมูลลับทำงานผ่าน Full Release Validation หรือจากรีเฟอเรนซ์เวิร์กโฟลว์ main/release เพื่อให้ตรรกะของเวิร์กโฟลว์และข้อมูลลับยังคงอยู่ภายใต้การควบคุม

  • 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 (หรือเวอร์ชันเบต้า/เวอร์ชันแก้ไขที่ตรงกัน) เพื่อตรวจสอบเส้นทางการติดตั้งจากรีจิสทรีที่เผยแพร่แล้วในคำนำหน้าชั่วคราวใหม่

  • หลังเผยแพร่เบต้า ให้เรียกใช้ [email protected] 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 จริงต้องผ่าน npm preflight_run_id ที่สำเร็จ
    • การประสานงานเผยแพร่และการตรวจสอบก่อนเริ่มสำหรับเบต้าและสเตเบิลตามปกติใช้ main ที่เชื่อถือได้กับแท็กเป้าหมายที่ตรงกันทุกประการ การเผยแพร่และการตรวจสอบก่อนเริ่มสำหรับ Tideclaw alpha ใช้แบรนช์ alpha ที่ตรงกัน
    • รีลีส 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 จริงต้องผ่าน macOS preflight_run_id และ validate_run_id ที่สำเร็จ
    • เส้นทางการเผยแพร่จริงจะเลื่อนขั้นอาร์ติแฟกต์ที่เตรียมไว้ แทนที่จะบิลด์ใหม่อีกครั้ง

  • สำหรับรีลีสแก้ไขแบบสเตเบิล เช่น YYYY.M.PATCH-N ตัวตรวจสอบหลังการเผยแพร่ยังตรวจสอบเส้นทางอัปเกรดด้วยคำนำหน้าชั่วคราวเดียวกันจาก YYYY.M.PATCH ไปยัง YYYY.M.PATCH-N เพื่อให้การแก้ไขรีลีสไม่สามารถปล่อยให้การติดตั้งแบบโกลบอลรุ่นเก่าค้างอยู่กับเพย์โหลดสเตเบิลพื้นฐานโดยไม่มีการแจ้งเตือน

  • การตรวจสอบก่อนเริ่มรีลีส npm จะล้มเหลวแบบปิด เว้นแต่ tarball จะมีทั้ง dist/control-ui/index.html และเพย์โหลด dist/control-ui/assets/ ที่ไม่ว่างเปล่า เพื่อไม่ให้เราเผยแพร่แดชบอร์ดเบราว์เซอร์ที่ว่างเปล่าอีก

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

  • pnpm test:install:smoke ยังบังคับใช้งบประมาณ unpackedSize ของ npm pack กับ tarball อัปเดตแคนดิเดตด้วย เพื่อให้ E2E ของตัวติดตั้งตรวจพบขนาดแพ็กเกจที่เพิ่มขึ้นโดยไม่ตั้งใจก่อนเข้าสู่เส้นทางเผยแพร่รีลีส

  • หากงานรีลีสแก้ไขการวางแผน CI แมนิเฟสต์เวลาทำงานของส่วนขยาย หรือเมทริกซ์การทดสอบส่วนขยาย ให้สร้างเอาต์พุตเมทริกซ์ plugin-prerelease-extension-shard ที่ตัววางแผนเป็นเจ้าของขึ้นใหม่จาก .github/workflows/plugin-prerelease.yml และตรวจสอบก่อนอนุมัติ เพื่อไม่ให้บันทึกประจำรุ่นอธิบายเลย์เอาต์ CI ที่ล้าสมัย

  • ความพร้อมของรีลีส macOS แบบสเตเบิลยังรวมถึงพื้นผิวของตัวอัปเดตด้วย: รีลีส GitHub ต้องมี .zip, .dmg และ .dSYM.zip ที่บรรจุแพ็กเกจแล้ว; appcast.xml บน main ต้องชี้ไปยังไฟล์ zip สเตเบิลใหม่หลังเผยแพร่ (เวิร์กโฟลว์เผยแพร่ macOS จะคอมมิตไฟล์นี้โดยอัตโนมัติ หรือเปิด appcast PR เมื่อการพุชโดยตรงถูกบล็อก); แอปที่บรรจุแพ็กเกจแล้วต้องคงรหัสบันเดิลที่ไม่ใช่ดีบัก URL ฟีด Sparkle ที่ไม่ว่างเปล่า และ CFBundleVersion ที่เท่ากับหรือสูงกว่าค่าขั้นต่ำของบิลด์ Sparkle มาตรฐานสำหรับเวอร์ชันรีลีสนั้น

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

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

bash
pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

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

หลังจาก Code SHA เป็นสีเขียว ให้คอมมิตเฉพาะ CHANGELOG.md และเรียกใช้ตัวช่วยเดิมด้วย Release SHA:

bash
pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH

เวิร์กโฟลว์หลักครั้งที่สองจะนำหลักฐานผลิตภัณฑ์กลับมาใช้ใหม่ก็ต่อเมื่อ GitHub พิสูจน์ว่า Release SHA สืบทอดจาก Code SHA และชุดพาธที่เปลี่ยนแปลงทั้งหมดเป็น CHANGELOG.md ทุกประการ เวิร์กโฟลว์จะบันทึก changelog-only-release-v1 และไม่สั่งให้เวิร์กโฟลว์ย่อยของผลิตภัณฑ์ทำงาน การตรวจสอบก่อนเริ่ม npm และการยอมรับแพ็กเกจ/การติดตั้งยังคงทำงานบน Release SHA เนื่องจากไบต์ของ tarball เปลี่ยนแปลง

สำหรับ Code SHA ใหม่ เวิร์กโฟลว์จะแก้ไขเป้าหมาย สั่งให้ CI แบบเรียกใช้ด้วยตนเองทำงาน แล้วจึงสั่งให้ OpenClaw Release Checks ทำงาน OpenClaw Release Checks จะกระจายงานไปยังการทดสอบควันการติดตั้ง การตรวจสอบรีลีสข้ามระบบปฏิบัติการ ความครอบคลุมเส้นทางรีลีส Docker แบบสด/E2E เมื่อเปิดใช้การแช่ทดสอบ การยอมรับแพ็กเกจพร้อม 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 ยังคง ถูกข้าม

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

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

ใช้ release_profile เพื่อเลือกขอบเขตความครอบคลุมแบบสด/ของผู้ให้บริการ:

  • beta: เส้นทาง 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 และนำอาร์ติแฟกต์นั้นกลับมาใช้ในการตรวจสอบข้ามระบบปฏิบัติการ การยอมรับแพ็กเกจ และเส้นทางรีลีส Docker เมื่อการแช่ทดสอบทำงาน วิธีนี้ทำให้กล่องที่เกี่ยวข้องกับแพ็กเกจทั้งหมดใช้ไบต์ชุดเดียวกันและหลีกเลี่ยงการบิลด์แพ็กเกจซ้ำ หลังจากเบต้าอยู่บน npm แล้ว ให้ตั้งค่า [email protected] เพื่อให้การตรวจสอบรีลีสดาวน์โหลดแพ็กเกจที่เผยแพร่แล้วเพียงครั้งเดียว แยก SHA ของซอร์สบิลด์จาก dist/build-info.json และนำอาร์ติแฟกต์นั้นกลับมาใช้สำหรับเลนข้ามระบบปฏิบัติการ การยอมรับแพ็กเกจ เส้นทางรีลีส Docker และ Telegram ของแพ็กเกจ

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

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

bash
# ตรวจสอบ Code SHA ที่ผลิตภัณฑ์เสร็จสมบูรณ์pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH # ตรวจสอบ Release SHA ที่เปลี่ยนเฉพาะ changelog โดยใช้หลักฐานผลิตภัณฑ์จาก Code SHA ซ้ำpnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH # หลังเผยแพร่ beta ให้เพิ่ม Telegram E2E สำหรับแพ็กเกจที่เผยแพร่แล้วpnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH \  -f [email protected] \  -f [email protected] \  -f npm_telegram_provider_mode=mock-openai

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

rerun_group=all อาจใช้การรันชุดรวมที่ผ่านก่อนหน้านี้ซ้ำได้ เมื่อโปรไฟล์รีลีส การตั้งค่า soak ที่มีผล และอินพุตการตรวจสอบตรงกัน และ target SHA เหมือนกัน หรือเป้าหมายใหม่เป็น descendant ที่มีชุดพาธที่เปลี่ยนแปลงทั้งหมด ตรงกับ CHANGELOG.md ทุกประการ การใช้เป้าหมายเดิมซ้ำจะบันทึก exact-target-full-validation-v1; Release SHA หลังการตรวจสอบจะบันทึก changelog-only-release-v1 โดยกรณีหลังจะใช้ซ้ำเฉพาะการตรวจสอบผลิตภัณฑ์เท่านั้น ส่วนการตรวจสอบล่วงหน้าของ npm ไบต์ของแพ็กเกจ ที่มาของบันทึกประจำรุ่น และการยอมรับการติดตั้ง/อัปเดต ยังต้องรันกับ Release SHA การเปลี่ยนแปลงเวอร์ชัน ซอร์ส ไฟล์ที่สร้างขึ้น การอ้างอิง แพ็กเกจ หรือเป้าหมายที่เวิร์กโฟลว์เป็นเจ้าของ ต้องใช้ Code SHA ใหม่ และการตรวจสอบฉบับเต็มใหม่ การรันชุดรวมที่ใหม่กว่าสำหรับ ref release/* และ กลุ่มการรันซ้ำเดียวกัน จะแทนที่รายการที่กำลังดำเนินการโดยอัตโนมัติ ส่ง reuse_evidence=false เพื่อบังคับให้รันฉบับเต็มใหม่

สำหรับการกู้คืนที่มีขอบเขต ให้ส่ง rerun_group ไปยังชุดรวม all คือการรัน release candidate จริง, 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; การรันแบบเต็ม/ทั้งหมดจะใช้ Telegram E2E ของแพ็กเกจมาตรฐานภายใน Package Acceptance การรันซ้ำข้ามระบบปฏิบัติการแบบเจาะจงสามารถเพิ่ม cross_os_suite_filter=windows/packaged-upgrade หรือตัวกรองระบบปฏิบัติการ/ชุดทดสอบอื่นได้ ความล้มเหลวของการตรวจสอบรีลีส QA จะบล็อกการตรวจสอบรีลีสตามปกติ รวมถึงความคลาดเคลื่อนของ dynamic tool ของ OpenClaw ที่กำหนดให้ตรวจสอบในระดับมาตรฐาน การรัน Tideclaw alpha ยังอาจถือว่าเลนตรวจสอบรีลีสที่ไม่เกี่ยวกับความปลอดภัยของแพ็กเกจเป็นเพียงคำแนะนำ เมื่อใช้ release_profile=beta ชุดทดสอบผู้ให้บริการจริง Run repo/live E2E validation จะเป็นเพียงคำแนะนำ (คำเตือน ไม่ใช่ตัวบล็อก) ส่วนโปรไฟล์ stable และ full ยังคงใช้เป็นตัวบล็อก เมื่อ live_suite_filter ร้องขอเลน QA แบบใช้งานจริงที่มีเกตอย่างชัดเจน เช่น Discord, WhatsApp หรือ Slack ต้องเปิดใช้งานตัวแปร repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED ที่ตรงกัน มิฉะนั้นการเก็บอินพุตจะล้มเหลวแทนที่จะข้ามเลนโดยไม่แจ้ง

Vitest

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

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

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

รัน CI แบบแมนนวลโดยตรงเฉพาะเมื่อรีลีสต้องการ CI ปกติที่กำหนดผลได้แน่นอน แต่ไม่ต้องใช้กล่อง Docker, QA Lab, การใช้งานจริง, ข้ามระบบปฏิบัติการ หรือแพ็กเกจ ใช้คำสั่งแรกสำหรับ CI โดยตรงที่ไม่รวม Android เพิ่ม include_android=true เมื่อ CI ของ release candidate ที่รันโดยตรงต้องครอบคลุม 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 กล่องนี้ตรวจสอบ release candidate ผ่านสภาพแวดล้อม Docker ที่จัดแพ็กเกจแล้ว แทนการใช้เฉพาะการทดสอบระดับซอร์ส

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

  • การทดสอบ smoke การติดตั้งแบบเต็ม โดยเปิดใช้การทดสอบ smoke การติดตั้ง Bun แบบ global ที่ทำงานช้า
  • การเตรียม/ใช้ซ้ำอิมเมจ smoke จาก Dockerfile รากตาม target SHA โดยงาน smoke สำหรับ QR, root/gateway และ installer/Bun ทำงานเป็น shard ของ 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 บน runner เฉพาะที่มีดิสก์ขนาดใหญ่เมื่อมีการร้องขอ
  • เลนติดตั้ง/ถอนการติดตั้ง 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 สำหรับรีลีสประกอบด้วย:

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

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

แพ็กเกจ

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

แหล่งที่มาของ candidate ที่รองรับ:

  • source=npm: openclaw@beta, openclaw@latest หรือเวอร์ชันรีลีส OpenClaw ที่ระบุชัดเจน
  • source=ref: แพ็ก branch, tag หรือ commit SHA แบบเต็มของ package_ref ที่เชื่อถือได้ ด้วยชุดควบคุม workflow_ref ที่เลือก
  • source=url: ดาวน์โหลด .tgz ผ่าน HTTPS สาธารณะโดยต้องมี package_sha256; ระบบจะปฏิเสธข้อมูลประจำตัวใน URL, พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น, ชื่อโฮสต์หรือแอดเดรสที่แก้ไขได้ซึ่งเป็นแบบ private/internal/special-use และการเปลี่ยนเส้นทางที่ไม่ปลอดภัย
  • 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 จะคงการตรวจสอบ migration, update, การอัปเกรด VPS ที่จัดการโดย root, การรีสตาร์ตหลังอัปเดตเมื่อกำหนดค่าการยืนยันตัวตนแล้ว, การติดตั้ง ClawHub skill แบบใช้งานจริง, การล้าง dependency ของ Plugin ที่ล้าสมัย, fixture ของ Plugin แบบออฟไลน์, การอัปเดต Plugin, การเสริมความแข็งแกร่งต่อการหลบเลี่ยงการผูกคำสั่งของ Plugin และ QA ของแพ็กเกจ Telegram โดยใช้ tarball ที่แก้ไขแล้วชุดเดียวกัน การตรวจสอบรีลีสแบบบล็อกจะใช้ baseline ของแพ็กเกจล่าสุดที่เผยแพร่ตามค่าเริ่มต้น ส่วนโปรไฟล์ beta ที่ใช้ run_release_soak=true, release_profile=stable หรือ release_profile=full จะขยายการกวาดตรวจผู้รอดจากการอัปเกรดแพ็กเกจที่เผยแพร่แล้วไปยัง last-stable-4 รวมถึง baseline ที่ปักหมุด 2026.4.23, 2026.5.2 และ 2026.4.15 พร้อมสถานการณ์ reported-issues ใช้ Package Acceptance กับ source=npm สำหรับ candidate ที่เผยแพร่แล้ว, source=ref สำหรับ tarball npm ภายในเครื่องที่อิง SHA ก่อนเผยแพร่, source=trusted-url สำหรับมิเรอร์องค์กร/ส่วนตัวที่ผู้ดูแลเป็นเจ้าของ หรือ source=artifact สำหรับ tarball ที่เตรียมไว้และอัปโหลดโดยการรัน GitHub Actions อื่น

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

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

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

ใช้โปรไฟล์ 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 [email protected]

โปรไฟล์แพ็กเกจที่ใช้บ่อย:

  • 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 เวิร์กโฟลว์จะส่ง tarball package-under-test ที่ได้รับการระบุแล้วไปยังเลน Telegram; เวิร์กโฟลว์ Telegram แบบสแตนด์อโลนยังคงยอมรับข้อมูลจำเพาะ npm ที่เผยแพร่แล้วสำหรับการตรวจสอบหลังเผยแพร่

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

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

  1. เช็กเอาต์แท็กรีลีสและระบุ SHA ของคอมมิต
  2. ตรวจสอบว่าแท็กเข้าถึงได้จาก main หรือ release/* (หรือสาขาอัลฟาของ Tideclaw สำหรับอัลฟาพรีรีลีส)
  3. รัน pnpm plugins:sync:check
  4. สั่งรัน Plugin NPM Release ด้วย publish_scope=all-publishable และ ref=<release-sha>
  5. สั่งรัน Plugin ClawHub Release ด้วยขอบเขตและ SHA เดียวกัน
  6. สั่งรัน OpenClaw NPM Release ด้วยแท็กรีลีส, npm dist-tag และ preflight_run_id ที่บันทึกไว้ หลังจากตรวจสอบ full_release_validation_run_id ที่บันทึกไว้และครั้งที่รันอย่างตรงกัน
  7. สำหรับรีลีสเสถียร ให้สร้างหรืออัปเดต GitHub release เป็นฉบับร่าง สั่งรัน 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

การเผยแพร่รีลีสเสถียรไปยัง 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, เผยแพร่ไบต์ของแพ็กเกจ หรือเปลี่ยนการกำหนดค่า trusted publisher เวิร์กโฟลว์ยังคงระบุแผนรีจิสทรีจริง เช็กเอาต์และแพ็กเป้าหมายเฉพาะในงานที่ไม่มีข้อมูลลับ จัดเตรียม ชุดเครื่องมือ ClawHub ที่ล็อกไว้ และตรวจสอบอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้และ สลัก/ข้อมูลประจำตัวของแพ็กเกจก่อนมีแท็กรีลีส อนุมัติสภาพแวดล้อม clawhub-plugin-bootstrap หลังจากงานแพ็กที่ไม่มีข้อมูลลับ เสร็จสิ้นแล้วเท่านั้น; งานตรวจสอบที่ได้รับการป้องกันนี้ไม่มีข้อมูลประจำตัวหรือคำสั่งเปลี่ยนแปลงข้อมูล

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

งานแพ็ก อัปโหลดอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้หนึ่งรายการ โดยส่งชื่อ, ID/ไดเจสต์ของอาร์ติแฟกต์ Actions, การรัน/ครั้งที่รันของผู้สร้าง, SHA เป้าหมาย และ SHA-256/ขนาดของ tarball ต่อแพ็กเกจ ไปยังงานตรวจสอบและงานที่ได้รับการป้องกัน งานที่ได้รับการป้องกันจะเช็กเอาต์เฉพาะเครื่องมือ main ที่เชื่อถือได้ ตรวจสอบทูเพิลของอาร์ติแฟกต์ผ่าน GitHub API ดาวน์โหลด ด้วย ID อาร์ติแฟกต์ที่ตรงกัน แฮช tarball ทุกไฟล์ซ้ำ และตรวจสอบพาธ TAR ภายในเครื่องและ ข้อมูลประจำตัวของแพ็กเกจด้วยกฎการทำให้ USTAR เป็นรูปแบบมาตรฐานของ CLI ที่ปักหมุดไว้ จากนั้นตัวเลือก ทุกรายการจะผ่านการทดลองเผยแพร่ของ CLI ที่ปักหมุดไว้ ซึ่งจะส่งคืนผลก่อน การค้นหารีจิสทรีหรือการตรวจสอบสิทธิ์ ตัวกรองล่วงหน้าของงานข้อมูลประจำตัวจำกัด ClawPack ที่บีบอัดไว้ ที่ 120 MiB, เพย์โหลดไฟล์รวมที่ 50 MiB, ข้อมูล TAR เมื่อขยายแล้วที่ 64 MiB และ จำนวนรายการ TAR ที่ 10,000 การซ่อมแซม trusted-publisher ของแพ็กเกจที่มีอยู่ยังคง เป็นการกำหนดค่าเท่านั้น แต่ยังคงแพ็กเป้าหมายและกำหนดให้แท็กที่ร้องขอ ตรงกับไบต์และเมทาดาทาของรีจิสทรีอย่างสมบูรณ์ก่อนเปลี่ยนการกำหนดค่า trusted-publisher การตรวจสอบหลังเผยแพร่จะดาวน์โหลดอาร์ติแฟกต์ 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: ID การรันก่อนดำเนินการที่สำเร็จและมีอยู่แล้ว ซึ่งจำเป็นในเส้นทางเผยแพร่จริง เพื่อให้เวิร์กโฟลว์นำ tarball ที่เตรียมไว้กลับมาใช้แทนการสร้างใหม่
  • full_release_validation_run_id: ID การรัน Full Release Validation ที่สำเร็จสำหรับแท็ก/SHA นี้ ซึ่งจำเป็นสำหรับการเผยแพร่จริง การเผยแพร่เบตาอาจดำเนินต่อโดยมีเพียงการตรวจสอบก่อนดำเนินการพร้อมคำเตือน แต่การเลื่อนรีลีสเสถียร/latest ยังคงจำเป็นต้องใช้ค่านี้
  • full_release_validation_run_attempt: ครั้งที่รันซึ่งเป็นจำนวนบวกที่ตรงกันและจับคู่กับ full_release_validation_run_id; จำเป็นทุกครั้งที่ระบุ ID การรัน เพื่อไม่ให้การรันซ้ำเปลี่ยนหลักฐานการอนุญาตระหว่างการเผยแพร่
  • release_publish_run_id: ID การรัน OpenClaw Release Publish ที่ได้รับอนุมัติ; จำเป็นเมื่อเวิร์กโฟลว์นี้ถูกสั่งรันโดยตัวแม่นั้น (การเรียกเผยแพร่จริงโดยตัวกระทำที่เป็นบอต)
  • plugin_npm_run_id: 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 จะข้ามเกณฑ์คุณสมบัติ 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 มาตรฐานที่ส่วนปลายตรงกัน โดยจะไม่ย้าย latest หรือ beta ของ Plugin แพ็กเกจเวอร์ชันใหม่จะได้รับ extended-stable แบบอะตอม ผ่านการเผยแพร่ที่เชื่อถือได้ด้วย OIDC (npm publish --tag extended-stable); เวิร์กโฟลว์ต้นทางนี้ ไม่ใช้ npm dist-tag add ที่ตรวจสอบสิทธิ์ด้วยโทเค็น การลองใหม่ จะข้ามเวอร์ชันที่ตรงกันซึ่งมีอยู่แล้วใน npm จากนั้นจะล้มเหลวแบบปิด เว้นแต่การอ่านกลับอย่างสมบูรณ์ จะยืนยันว่าทุกแพ็กเกจและแท็ก extended-stable ที่ตรงกันได้ลู่เข้าสู่สถานะเดียวกันแล้ว

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

  • tag: แท็กรีลีสที่จำเป็น; ต้องมีอยู่แล้ว
  • preflight_run_id: ID การรันก่อนดำเนินการ OpenClaw NPM Release ที่สำเร็จ; จำเป็นเมื่อ publish_openclaw_npm=true หรือ plugin_publish_scope=all-publishable
  • full_release_validation_run_id: ID การรัน Full Release Validation ที่สำเร็จ; จำเป็นเมื่อ publish_openclaw_npm=true หรือ plugin_publish_scope=all-publishable
  • full_release_validation_run_attempt: ครั้งที่รันซึ่งเป็นจำนวนบวกที่ตรงกันและจับคู่กับ full_release_validation_run_id; จำเป็นทุกครั้งที่ระบุ ID การรัน
  • windows_node_tag: แท็กรีลีส openclaw/openclaw-windows-node ที่ไม่ใช่พรีรีลีสและตรงกัน; จำเป็นสำหรับการเผยแพร่ OpenClaw แบบเสถียร
  • windows_node_installer_digests: แมป JSON แบบกะทัดรัดที่ตัวเลือกได้รับการอนุมัติ ซึ่งแมปชื่อตัวติดตั้ง Windows ปัจจุบันกับไดเจสต์ sha256: ที่ปักหมุดไว้; จำเป็นสำหรับการเผยแพร่ OpenClaw แบบเสถียร
  • npm_telegram_run_id: 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 และการทดสอบ soak การอยู่รอดหลังอัปเกรดทั้งหมดนับตั้งแต่ต้นสำหรับการตรวจสอบรีลีสเบตา ตัวเลือกนี้จะถูกบังคับเปิดโดย 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 และงานสำหรับแพลตฟอร์มอื่นด้วย ไม่ใช่เส้นทางเสถียรระยะยาวแบบ npm เท่านั้นรายเดือน .33+ ที่จัดทำเอกสารไว้ด้านบนของหน้านี้

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

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

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

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

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

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

ที่เกี่ยวข้อง

Was this useful?
On this page

On this page