ไปป์ไลน์ CI

OpenClaw CI ทำงานเมื่อมีการพุชไปยัง main (เส้นทาง Markdown และ docs/** จะถูกละเว้น ในทริกเกอร์) ในทุก pull request ที่ไม่ใช่แบบร่าง และเมื่อสั่งทำงานด้วยตนเอง การพุชไปยัง main หลักจะทำงานได้ครั้งละหนึ่งรอบ: กลุ่มการทำงานพร้อมกัน CI อนุญาตให้ วงจรการผสานรวมหนึ่งรอบทำงานจนเสร็จ ขณะที่ GitHub เก็บไว้เฉพาะการพุชที่รอดำเนินการล่าสุด การผสานใหม่จะแทนที่รอบที่รอดำเนินการนั้น แทนที่จะยกเลิกงานที่ ลงทะเบียนเมทริกซ์ Blacksmith แล้ว ส่วน pull request ยังคงยกเลิก head ที่ถูกแทนที่ และการสั่งทำงานด้วยตนเองใช้กลุ่มที่แยกจากกัน preflight จะจำแนก diff และ ปิดเลนที่ใช้ทรัพยากรมากเมื่อมีการเปลี่ยนแปลงเฉพาะส่วนที่ไม่เกี่ยวข้อง การเรียกใช้ workflow_dispatch ด้วยตนเองจะจงใจข้ามการกำหนดขอบเขตอัจฉริยะและกระจายงานไปยัง กราฟทั้งหมดสำหรับตัวเลือกที่จะเผยแพร่และการตรวจสอบความถูกต้องแบบกว้าง เลน Android ยังคง ต้องเปิดใช้โดยเฉพาะผ่าน include_android (หรืออินพุต release_gate) การครอบคลุม Plugin เฉพาะรุ่นเผยแพร่อยู่ในเวิร์กโฟลว์ Plugin Prerelease ที่แยกต่างหาก และทำงานจาก Full Release Validation หรือการสั่งทำงานด้วยตนเอง อย่างชัดเจนเท่านั้น

ภาพรวมไปป์ไลน์

เวิร์กโฟลว์ Periphery แบบแยกเดี่ยวบังคับให้ไม่พบโค้ดที่ไม่ได้ใช้งานสำหรับแอป iOS และ macOS เวิร์กโฟลว์ OpenClawKit ที่ใช้ร่วมกันจะสแกนผู้ใช้ทั้งสองแบบขนาน และรายงานการประกาศเฉพาะเมื่อ Periphery ส่ง Swift USR เดียวกันจากทั้งสองบิลด์ สัญญาสคีมา OpenClawProtocol/GatewayModels.swift ที่สร้างขึ้นจะคงไว้ในฐานะโค้ดที่ตัวสร้างเป็นเจ้าของ แทนที่จะถือว่าเป็นโค้ดที่ไม่ได้ใช้งานเฉพาะแอป

ลำดับการหยุดเร็วเมื่อเกิดข้อผิดพลาด

1. preflight กำหนดว่าเลนใดจะมีอยู่เลย ตรรกะ docs-scope และ changed-scope เป็นขั้นตอนภายในงานนี้ ไม่ใช่งานแบบแยกเดี่ยว main หลักจะเริ่มทันที แต่กลุ่มการทำงานพร้อมกันอนุญาตให้ทำงานจนเสร็จได้เพียงหนึ่งรอบ และรวมการพุชภายหลังให้เหลือรอบรอดำเนินการล่าสุดหนึ่งรอบ การพุช main ที่เกี่ยวข้องกับ Node ยังจัดลำดับตัวเขียนดิสก์การขึ้นต่อกันเพียงตัวเดียวและการบำรุงรักษาขนาดไว้ที่นี่ ก่อนที่งานปลายทางจะเมานต์คีย์ได้; Blacksmith อาจเปิดเผยคอมมิตใหม่ให้เฉพาะการเรียกใช้เวิร์กโฟลว์ครั้งถัดไป ดังนั้นผู้ใช้ในรอบเดียวกันจึงยังคงใช้ทางเลือกสำรองภายในที่ตรวจสอบด้วยมาร์กเกอร์
2. security-fast, check-*, check-additional-*, check-docs และ skills-python จะล้มเหลวอย่างรวดเร็วโดยไม่รอเมทริกซ์งานอาร์ติแฟกต์และแพลตฟอร์มที่หนักกว่า
3. build-artifacts และการตรวจสอบภาษา locale ทำงานทับซ้อนกับเลน Linux แบบเร็ว PR ซอร์สของ Control UI และแอปเนทีฟจะไม่รวมสแนปช็อต/ทรัพยากร locale ที่สร้างขึ้น; เวิร์กโฟลว์รีเฟรชแบบเรียงลำดับจะซ่อมแซมและผสาน PR ที่สร้างขึ้นและแยกไว้โดยอัตโนมัติในเบื้องหลัง CI ของซอร์สยังคงบล็อกคลังรายการซอร์สที่ล้าสมัยและการเรียกใช้การทำให้เป็นภาษาท้องถิ่นที่ไม่ปลอดภัย PR ที่สร้างขึ้น, CI แบบสั่งด้วยตนเอง และการเตรียมรุ่นเผยแพร่จะบังคับให้คำแปลและสิ่งที่สร้างเฉพาะแพลตฟอร์มสอดคล้องกันทั้งหมด แบรนช์ release/YYYY.M.PATCH หลักอาจรวมการซ่อมแซม locale สำหรับการเตรียมรุ่นเผยแพร่ไว้กับเอาต์พุตรุ่นเผยแพร่ที่สร้างขึ้นอื่น ๆ
4. จากนั้นเลนแพลตฟอร์มและรันไทม์ที่หนักกว่าจะกระจายงานออกไป: checks-fast-core, checks-fast-contracts-plugins-*, checks-fast-contracts-channels-*, checks-node-*, checks-windows, macos-node, macos-swift, ios-build และ android
5. openclaw/ci-gate รอทุกเลนที่เลือก การตรวจสอบล่วงหน้าและความปลอดภัยต้องสำเร็จ; งานปลายทางข้ามได้เฉพาะเมื่อรายการกำกับไม่ได้เลือกงานเหล่านั้น เลนที่เลือกซึ่งล้มเหลวหรือถูกยกเลิกจะทำให้ผลรวมล้มเหลว

ตัวประสานงานการผสานอาจนำ openclaw/ci-gate ที่ผ่านสำเร็จและผ่านการยืนยันตัวตนแล้วกลับมาใช้ซ้ำ สำหรับ head ของ pull request เดิมได้นานสูงสุด 24 ชั่วโมง วิธีนี้หลีกเลี่ยงการเขียน แบรนช์ของผู้มีส่วนร่วมใหม่หลังจากมีการเปลี่ยนแปลง main ที่ไม่เกี่ยวข้อง ผลลัพธ์ที่นำกลับมาใช้ซ้ำได้จะไม่ แทนที่การตรวจสอบ test-merge แบบเข้มงวดที่แยกต่างหาก ซึ่ง App เป็นเจ้าของและตรวจเทียบกับ main ปัจจุบัน การเรียกใช้ซ้ำที่รอดำเนินการหรือล้มเหลวในภายหลังจะไม่ลบล้างผลลัพธ์ที่สำเร็จก่อนหน้า สำหรับ head ที่ไม่เปลี่ยนแปลงนั้นภายในช่วงเวลาความสดใหม่

กฎของสาขาเริ่มต้นกำหนดให้มีการตรวจสอบ openclaw/ci-gate ที่ GitHub Actions เป็นเจ้าของ ผู้ดูแลและผู้ดูแลระบบของรีโพซิทอรีมีการข้ามแบบฉุกเฉินที่มีการตรวจสอบย้อนหลัง ซึ่งมีไว้เฉพาะสำหรับการนำการเปลี่ยนแปลงเข้าโดยตรงแบบ fast-forward ที่ลงนามแล้วเท่านั้น ส่วนกฎระดับองค์กรยังคงบล็อกการลบและการอัปเดตแบบ non-fast-forward การผสาน pull request ตามปกติควรใช้เกตต่อไปแทนการข้ามไปป์ไลน์ CI ที่ล้มเหลว การตรวจสอบ test-merge แบบเข้มงวดที่ App เป็นเจ้าของซึ่งแยกต่างหากยังคงผูก head เข้ากับ main ปัจจุบัน

GitHub อาจทำเครื่องหมายงานของ pull request ที่ถูกแทนที่เป็น cancelled เมื่อมี head ใหม่กว่าถูกนำเข้า ให้ถือว่านั่นเป็นสัญญาณรบกวนของ CI เว้นแต่การรันล่าสุดของ PR เดียวกันจะล้มเหลวด้วย การรัน main ที่เป็นมาตรฐานจะไม่ถูกยกเลิกหลังผ่านการรับเข้า เมื่อมีทราฟฟิกการผสานเข้ามา GitHub จะแทนที่เฉพาะการรันเก่าที่ยังรอดำเนินการด้วย tip ล่าสุด งาน Matrix ใช้ fail-fast: false และ build-artifacts รายงานความล้มเหลวของช่องทางแบบฝัง ขอบเขตการรองรับของ core และการเฝ้าดู Gateway โดยตรง แทนการจัดคิวงานตรวจสอบขนาดเล็ก คีย์การทำงานพร้อมกันอัตโนมัติของ CI มีการกำหนดเวอร์ชัน (CI-v7-*) เพื่อไม่ให้ซอมบี้ฝั่ง GitHub ในกลุ่มคิวเก่าบล็อกการรัน main ที่ใหม่กว่าอย่างไม่มีกำหนด การรันชุดทดสอบเต็มรูปแบบด้วยตนเองใช้ CI-manual-v1-* และไม่ยกเลิกการรันที่กำลังดำเนินอยู่ ตัวป้องกันหน่วยความจำเมื่อเริ่มต้นของรายการ Plugin กำหนดเพดานไว้ที่ 350 MiB บน Blacksmith Linux แบบ self-hosted และอนุญาต 425 MiB บน Linux ที่ GitHub โฮสต์ ซึ่งมีค่า RSS พื้นฐานสูงกว่าสำหรับ CLI ที่บิลด์แบบเดียวกัน

ใช้ pnpm ci:timings, pnpm ci:timings:recent หรือ node scripts/ci-run-timings.mjs <run-id> เพื่อสรุประยะเวลาจริง เวลารอคิว งานที่ช้าที่สุด ความล้มเหลว และแนวกั้น fanout pnpm-store-warmup จาก GitHub Actions งาน ci-timings-summary ภายในเวิร์กโฟลว์มีอยู่ใน ci.yml แต่ขณะนี้ถูกปิดใช้งาน (if: false) ให้รันตัวช่วยจับเวลาในเครื่องแทน สำหรับเวลาบิลด์ ให้ตรวจสอบขั้นตอน Build dist ของงาน build-artifacts: pnpm build:ci-artifacts แสดง [build-all] phase timings: และรวม ui:build นอกจากนี้ งานยังอัปโหลดอาร์ติแฟกต์ startup-memory

บริบทและหลักฐานของ PR

PR จากผู้มีส่วนร่วมภายนอกจะรันเกตตรวจสอบบริบทและหลักฐานของ PR จาก .github/workflows/real-behavior-proof.yml เวิร์กโฟลว์จะเช็กเอาต์ รีวิชันของเวิร์กโฟลว์ที่เชื่อถือได้ (github.workflow_sha) และประเมินเฉพาะเนื้อหาของ PR โดยไม่เรียกใช้โค้ดจากสาขาของผู้มีส่วนร่วม

เกตนี้ใช้กับผู้เขียน PR ที่ไม่ใช่เจ้าของรีโพซิทอรี สมาชิก ผู้ร่วมงาน หรือบอต เกตจะผ่านเมื่อเนื้อหาของ PR มีส่วน What Problem This Solves และ Evidence ที่ผู้เขียนจัดทำขึ้น หลักฐานอาจเป็นการทดสอบแบบเจาะจง ผลลัพธ์ CI ภาพหน้าจอ การบันทึก เอาต์พุตเทอร์มินัล การสังเกตการณ์สด บันทึกที่ปกปิดข้อมูลแล้ว หรือลิงก์อาร์ติแฟกต์ เนื้อหานี้ระบุเจตนาและการตรวจสอบความถูกต้องที่เป็นประโยชน์ ส่วนผู้รีวิวจะตรวจสอบโค้ด การทดสอบ และ CI เพื่อประเมินความถูกต้อง

เมื่อการตรวจสอบล้มเหลว ให้อัปเดตเนื้อหาของ PR แทนการพุชคอมมิตโค้ดเพิ่ม

ขอบเขตและการกำหนดเส้นทาง

ตรรกะขอบเขตอยู่ใน scripts/ci-changed-scope.mjs และครอบคลุมด้วยการทดสอบหน่วยใน src/scripts/ci-changed-scope.test.ts การสั่งรันด้วยตนเองจะข้ามการตรวจหาขอบเขตที่เปลี่ยนแปลง และทำให้ manifest ขั้นตรวจสอบเบื้องต้นทำงานเสมือนว่าทุกพื้นที่ในขอบเขตมีการเปลี่ยนแปลง

เวิร์กโฟลว์ Periphery แยกกันสำหรับ iOS และ macOS บังคับใช้นโยบายโค้ดที่ไม่ได้ใช้งานซึ่งต้องไม่มีข้อค้นพบเลย แต่ละเวิร์กโฟลว์จะรันเฉพาะเมื่อ pull request ที่ไม่ใช่ฉบับร่างแตะขอบเขตการสแกนแบบเนทีฟของตน หรือเมื่อถูกสั่งรันด้วยตนเอง

• การแก้ไขเวิร์กโฟลว์ CI ตรวจสอบกราฟ CI ของ Node การ lint เวิร์กโฟลว์ และเลน Windows (ci.yml เป็นตัวเรียกใช้) แต่ไม่บังคับให้บิลด์เนทีฟของ iOS, Android หรือ macOS ด้วยตัวเอง เลนของแพลตฟอร์มเหล่านั้นยังคงจำกัดขอบเขตไว้เฉพาะการเปลี่ยนแปลงซอร์สของแพลตฟอร์ม
• การตรวจสอบความสมเหตุสมผลของเวิร์กโฟลว์ รัน actionlint, zizmor กับไฟล์ YAML ของเวิร์กโฟลว์ทั้งหมด ตัวป้องกันการแทนค่า interpolation ของ composite action และตัวป้องกันเครื่องหมาย conflict งาน security-fast ที่จำกัดขอบเขตตาม PR ยังรัน zizmor กับไฟล์เวิร์กโฟลว์ที่เปลี่ยนแปลง เพื่อให้ข้อค้นพบด้านความปลอดภัยของเวิร์กโฟลว์ทำให้ล้มเหลวได้ตั้งแต่เนิ่น ๆ ในกราฟ CI หลัก
• เอกสารในการพุชไปยัง main จะถูกตรวจสอบโดยเวิร์กโฟลว์ Docs แบบสแตนด์อโลน โดยใช้มิเรอร์เอกสาร ClawHub เดียวกับ CI ดังนั้นการพุชที่มีทั้งโค้ดและเอกสารจะไม่จัดคิวชาร์ด check-docs ของ CI เพิ่มเติม Pull request และ CI ที่สั่งรันด้วยตนเองยังคงรัน check-docs จาก CI เมื่อเอกสารมีการเปลี่ยนแปลง
• TUI PTY รันในชาร์ด Linux Node checks-node-core-runtime-tui-pty สำหรับการเปลี่ยนแปลง TUI ชาร์ดนี้รัน test/vitest/vitest.tui-pty.config.ts พร้อม OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 จึงครอบคลุมทั้งเลนฟิกซ์เจอร์ TuiBackend ที่ให้ผลลัพธ์แน่นอน และการทดสอบ smoke tui --local ที่ช้ากว่าและจำลองเฉพาะปลายทางโมเดลภายนอก
• การแก้ไขเฉพาะการกำหนดเส้นทาง CI ชุดฟิกซ์เจอร์ทดสอบ core ขนาดเล็กที่งานแบบเร็วรันโดยตรง และการแก้ไขตัวช่วยสัญญา Plugin ในขอบเขตแคบ ใช้เส้นทาง manifest แบบเร็วสำหรับ Node เท่านั้น ได้แก่ preflight, security-fast และเฉพาะเลนแบบเร็วที่ได้รับผลกระทบจากการเปลี่ยนแปลง ได้แก่ งานกำหนดเส้นทาง CI checks-fast-core เพียงงานเดียว ชาร์ดสัญญา Plugin สองชาร์ด หรือทั้งสองอย่าง เส้นทางนี้ข้ามอาร์ติแฟกต์บิลด์ ความเข้ากันได้กับ Node 22 สัญญาของช่องทาง ชาร์ด core แบบเต็ม ชาร์ด Plugin ที่รวมมาให้ และเมทริกซ์ตัวป้องกันเพิ่มเติม
• การตรวจสอบ Node บน Windows จำกัดขอบเขตไว้เฉพาะตัวห่อหุ้มกระบวนการ/พาธสำหรับ Windows ตัวช่วยรัน npm/pnpm/UI การกำหนดค่าตัวจัดการแพ็กเกจ และพื้นผิวเวิร์กโฟลว์ CI ที่เรียกใช้เลนนั้น การเปลี่ยนแปลงซอร์ส Plugin การทดสอบ smoke การติดตั้ง และการเปลี่ยนแปลงเฉพาะการทดสอบที่ไม่เกี่ยวข้องยังคงอยู่บนเลน Linux Node

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

• สัญญา Plugin และสัญญาช่องทางต่างทำงานเป็นชาร์ดแบบถ่วงน้ำหนักสองชาร์ดที่ใช้ Blacksmith รองรับ พร้อมใช้รันเนอร์มาตรฐานของ GitHub เป็นทางเลือกสำรอง
• เลน fast/support ของยูนิตคอร์ทำงานแยกกัน ส่วนโครงสร้างพื้นฐานรันไทม์ของคอร์แบ่งเป็นชาร์ด process, shared, hooks, secrets และชาร์ดโดเมน Cron สามชาร์ด
• การตอบกลับอัตโนมัติทำงานเป็นเวิร์กเกอร์ที่ปรับสมดุล โดยซับทรีการตอบกลับแบ่งเป็นชาร์ด agent-runner, commands, dispatch, session และ state-routing
• การกำหนดค่า Gateway/เซิร์ฟเวอร์แบบเอเจนต์ (ระนาบควบคุม) แบ่งเป็นเลน chat, auth, model, HTTP/plugin, runtime และ startup แทนการรออาร์ติแฟกต์ที่สร้างเสร็จแล้ว
• CI ปกติรวมเฉพาะชาร์ดรูปแบบ include ของโครงสร้างพื้นฐานที่แยกอิสระไว้เป็นบันเดิลแบบกำหนดผลลัพธ์แน่นอน ซึ่งมีไฟล์ทดสอบไม่เกิน 64 ไฟล์ ช่วยลดเมทริกซ์ Node โดยไม่รวมชุดคำสั่ง/Cron ที่ไม่ได้แยกอิสระ, agents-core ที่มีสถานะ หรือชุด Gateway/เซิร์ฟเวอร์เข้าด้วยกัน ชุดงานหนักที่กำหนดตายตัวยังคงใช้ 8 vCPU ขณะที่เลนแบบบันเดิลและเลนที่มีน้ำหนักต่ำกว่าใช้ 4 vCPU
• Pull request ในรีโพซิทอรีมาตรฐานใช้ตัวแก้ไขการทดสอบที่เปลี่ยนแปลงซ้ำกับ diff ของทรีที่ผสานแบบสังเคราะห์ การเปลี่ยนแปลงที่ระบุได้แม่นยำจะเรียกใช้งาน Node เป้าหมายหนึ่งงาน โดยไฟล์ทดสอบที่เลือกแต่ละไฟล์จะมีกระบวนการของตนเองเพื่อคงการแยกชุดทดสอบที่มีสถานะไว้อย่างสมบูรณ์ ตัววางแผนรวมการทดสอบระดับเดียวกันกับรายการที่ขึ้นต่อกันตามกราฟการนำเข้า และย้อนกลับไปใช้แผนชุดทดสอบเต็มแบบกะทัดรัด 14 งานที่มีอยู่ สำหรับการเปลี่ยนแปลงแพ็กเกจ workspace, แพ็กเกจ/lockfile, ฮาร์เนสที่ใช้ร่วมกัน, การกำหนดค่าแบบแยก, การเปลี่ยนชื่อ หรือการลบ, การเปลี่ยนแปลงสัญญาส่วนขยายสาธารณะ, การทดสอบที่มีการตั้งค่าชาร์ดพิเศษ, เป้าหมายที่แก้ไขได้เพียงบางส่วนหรือว่างเปล่า, แผนพาธหรือเป้าหมายที่มีขนาดใหญ่เกินไป และข้อผิดพลาดของตัววางแผน แผนแบบกำหนดเป้าหมายจะคงเกตขอบเขตอาร์ติแฟกต์ที่สร้างทั้งหมดไว้เสมอ เนื่องจากสแกนเนอร์ของรีโพซิทอรีไม่สามารถอนุมานจากการนำเข้าได้ การพุช main เรียกใช้ชุดแบบกะทัดรัดเต็มรูปแบบเดียวกัน: เหตุการณ์พุชระหว่างกลางที่รอดำเนินการอาจถูกรวมกัน ดังนั้นการทำงานล่าสุดที่ยังคงอยู่ต้องตรวจสอบทรีการผสานรวมทั้งหมด ไม่ใช่เฉพาะ diff ของการพุชครั้งสุดท้ายเพียงครั้งเดียว การสั่งทำงานด้วยตนเองและเกตการเผยแพร่ยังคงใช้เมทริกซ์แบบระบุชื่อครบถ้วนต่อชาร์ด
• เมทริกซ์ Node แบบเต็มรับเครื่องมือแบบอนุกรมที่ช้าอย่างสม่ำเสมอ, ชาร์ดคำสั่งตอบกลับอัตโนมัติ และตัวเขียนแคช core-fast แบบกว้างก่อน วิธีนี้รักษาขีดจำกัด 28 งานไว้ พร้อมป้องกันไม่ให้งานบนเส้นทางวิกฤตและซีดการแปลงของการทำงานครั้งถัดไปเลื่อนไปยังระลอกภายหลัง
• การทดสอบเบราว์เซอร์, QA, สื่อ และ Plugin เบ็ดเตล็ดแบบกว้างใช้การกำหนดค่า Vitest เฉพาะของตนเองแทนตัวรวบรวม Plugin ที่ใช้ร่วมกัน ชาร์ดรูปแบบ include บันทึกรายการเวลาโดยใช้ชื่อชาร์ด CI เพื่อให้ .artifacts/vitest-shard-timings.json แยกการกำหนดค่าทั้งชุดออกจากชาร์ดที่กรองแล้วได้
• งานชาร์ด Linux Node เก็บรักษาแคชโมดูลบนระบบไฟล์รุ่นทดลองของ Vitest ผ่าน API แคช Actions ต้นทาง ซึ่ง Blacksmith เร่งความเร็วอย่างโปร่งใสบนรันเนอร์ของตน ทุกชาร์ด CI กู้คืนอย่างเดียวและแตกซีดที่ได้รับการป้องกันลงในรูทภายในรันเนอร์ของตนเอง จากนั้นแรปเปอร์ชาร์ดจะจัดไดเรกทอรีย่อยที่ใช้งานแยกกันให้กระบวนการ Vitest ที่ทำงานพร้อมกัน เฉพาะตัวอุ่นแคชรายวันที่ไม่ถูกยกเลิกหรือตัวอุ่นแคชที่สั่งทำงานอย่างชัดเจนเท่านั้นที่บันทึกอาร์ไคฟ์แบบเปลี่ยนแปลงไม่ได้ชุดใหม่ ดังนั้น Pull request จึงไม่สามารถเผยแพร่การแปลงหรือสร้างตระกูลแคชต่อ PR ได้ ลายนิ้วมืออินพุตการแปลงจะล้างรุ่นของ lockfile, แพ็กเกจ, tsconfig และการกำหนดค่า Vitest ที่เข้ากันไม่ได้ ตัวเขียนที่ได้รับการป้องกันจะสแกนและตัดแคชที่กู้คืนเหลือ 75% หลังจากมีขนาดเกิน 2 GiB Vitest แฮชรหัสโมดูล, เนื้อหาซอร์ส, สภาพแวดล้อม และการกำหนดค่าการแปลงที่แก้ไขแล้ว ดังนั้นการเปลี่ยนแปลงซอร์สบางส่วนตามปกติจะยังคงให้รายการที่ไม่เปลี่ยนแปลงอุ่นอยู่ ขณะที่โมดูลที่เปลี่ยนแปลงจะพลาดแคชอย่างปลอดภัย คำนำหน้าการกู้คืนแบบหยาบช่วยเชื่อมระหว่างการทำงานของเวิร์กโฟลว์ ส่วน LRU และการขับออกเมื่อไม่มีการใช้งานตามปกติของแคช Actions จะจำกัดอาร์ไคฟ์เก่าแบบเปลี่ยนแปลงไม่ได้
• งาน Linux Node ที่เชื่อถือได้ยังผูก pnpm store และ node_modules จากดิสก์การขึ้นต่อกันที่ได้รับการป้องกันหนึ่งชุดต่อสาย Node ที่รองรับ รายการแพ็กเกจ, การตั้งค่าการติดตั้ง, แพลตฟอร์มรันเนอร์ และแพตช์ Node ที่แน่นอนไม่รวมอยู่ในคีย์ดิสก์ โดยลายนิ้วมือของรันไทม์และอินพุตการติดตั้งที่แน่นอนจะตัดสินว่างานนำทรีกลับมาใช้ใหม่หรือติดตั้งใหม่และรีเฟรชดิสก์เดิม รายการต่างๆ จะถูกทำให้เป็นรูปแบบมาตรฐานก่อนแฮช ฮุกระดับรูทโดยตรงที่ผ่านการตรวจสอบจะคงไว้เฉพาะสคริปต์วงจรการติดตั้งของ pnpm ดังนั้นการแก้ไขการจัดรูปแบบและสคริปต์ทดสอบ/สร้างทั่วไปจะยังคงใช้ทรีการขึ้นต่อกันที่อุ่นอยู่ได้ การเปลี่ยนแปลงฮุกวงจรที่ไม่ได้รับการตรวจสอบจะล้มเหลวแบบปิดจนกว่าอินพุตซอร์สจะรวมอยู่ในสัญญาลายนิ้วมือ การเปลี่ยนแปลงการขึ้นต่อกัน, ตัวจัดการแพ็กเกจ, ซอร์สฮุก และ lockfile จะทำให้สแนปช็อตใช้ไม่ได้เสมอ ลายนิ้วมือที่ตรงกันเป็นเงื่อนไขจำเป็นแต่ไม่เพียงพอ: การตั้งค่ายังตรวจสอบอาร์ไคฟ์ importer และเช็กซัมรายการ จากนั้นตรวจสอบว่าการขึ้นต่อกันของ lockfile ที่อิงรีจิสทรีและ postinstall เก็บไว้ตรงกับรายการแพ็กเกจที่ Node แก้ไขจาก importer ของรายการเหล่านั้น เนื้อหา importer ที่ขาดหายหรือล้าสมัยจะย้อนกลับไปติดตั้งใหม่แทนการให้บริการ root hoist Pull request ที่สแนปช็อตแบบอ่านอย่างเดียวใช้ไม่ได้จะยกเลิกการผูก workspace และติดตั้งลงในพื้นที่จัดเก็บภายในรันเนอร์ เพื่อหลีกเลี่ยงการเขียนที่ช้าลงในโคลนที่ไม่สามารถเผยแพร่ได้ การติดตั้งแบบ cold บนดิสก์ถาวรจะปิดการลองดึงข้อมูลซ้ำภายในของ pnpm และพยายามติดตั้งแบบเต็มได้สูงสุดสามครั้งภายในขอบเขตที่กำหนดจาก store ที่อุ่นขึ้นเรื่อยๆ โดยการหมดเวลายังคงถือเป็นความล้มเหลว หลังจากกู้คืนโดยตรวจสอบเนื้อหาหรือติดตั้งแบบ frozen-lockfile แล้ว การตั้งค่าจะปิดการตรวจสอบการขึ้นต่อกันก่อนรันที่ซ้ำซ้อนของ pnpm: รีโพซิทอรีตั้งใจตัด node_modules ภายใน Plugin ซึ่ง pnpm จะถือว่าล้าสมัยและซ่อมผ่านการติดตั้งโดยนัยพร้อมกันที่ไม่ปลอดภัยระหว่างการกระจายงานชาร์ด การตรวจสอบล่วงหน้าของ main มาตรฐานเป็นตัวเขียนเพียงตัวเดียว และวัดขนาด store ทุกครั้งที่รีเฟรช โดยเรียกใช้ pnpm store prune เฉพาะเมื่อเวอร์ชันแพ็กเกจที่เลิกใช้แล้วทำให้ขนาดเกิน 8 GiB การเผยแพร่สแนปช็อตของ Blacksmith เป็นแบบอะซิงโครนัสแม้หลังงานตัวเขียนเสร็จสิ้น ดังนั้นการทำงานครั้งแรกหลังคีย์หรือลายนิ้วมือใหม่อาจยังคงเป็น cold ได้ การกู้คืนเครื่องหมายที่ตรงกันแบบแน่นอนและผ่านการตรวจสอบเนื้อหาในภายหลังเป็นหลักฐานการเปิดใช้งาน งาน CI ที่จำเป็นและ Pull request ได้รับโคลนแบบใช้แล้วทิ้ง ดังนั้นการเปลี่ยนแปลงการขึ้นต่อกันจึงไม่สร้างดิสก์ใหม่, สแนปช็อตที่แข่งขันกัน หรือล็อกแคชที่อาจยกเลิกการสร้าง
• งานชาร์ด Node และอาร์ติแฟกต์การสร้างยังกู้คืนแคชคอมไพล์แบบพกพาบนดิสก์ของ Node ผ่านแคช Actions แบบเปลี่ยนแปลงไม่ได้ เนมสเปซ test และ build ที่แยกจากกันป้องกันไม่ให้ตัวเขียนแทนที่อาร์ไคฟ์ของกันและกัน: ตัวอุ่นแคชการทดสอบตามกำหนดเวลาเป็นเจ้าของซีดทดสอบที่ได้รับการป้องกัน ขณะที่ build-artifacts อาจเผยแพร่อาร์ไคฟ์การสร้างที่ได้รับการป้องกันได้ไม่เกินหนึ่งชุดต่อวัน UTC จากการพุช main ที่เชื่อถือได้ งาน PR และงานทดสอบทั่วไปอ่านเฉพาะสแนปช็อตที่ได้รับการป้องกัน ดังนั้นไบต์โค้ดของฟีเจอร์บรานช์จะไม่เข้าสู่ซีดที่ใช้ร่วมกัน และทราฟฟิก PR จะไม่สร้างอาร์ไคฟ์แคช วิธีนี้นำไบต์โค้ด V8 กลับมาใช้ใหม่สำหรับการประสานงานที่โหลดโดย Node, เครื่องมือสร้าง และการขึ้นต่อกันภายนอกในพาธเช็กเอาต์ต่างๆ รวมถึงเมื่อมีการเปลี่ยนแปลงเพียงบางส่วนของกราฟซอร์ส กระบวนการลูก Vitest ปิดแคชคอมไพล์ที่สืบทอดมา เนื่องจากอาจเปิดใช้ความครอบคลุมภายในการกำหนดค่าแบบไดนามิก และความครอบคลุม V8 อาจสูญเสียความแม่นยำของตำแหน่งซอร์สเมื่อดีซีเรียลไลซ์สคริปต์จากไบต์โค้ด
• งานอาร์ติแฟกต์การสร้างยังเก็บรักษาเอาต์พุตขั้นตอน build-all ที่มีลายนิ้วมือตามเนื้อหา การประกาศ Plugin SDK ที่ CI สร้างขึ้นเองจะแฮชกราฟซอร์ส TypeScript/JSON ทั้งหมดที่รีโพซิทอรีเป็นเจ้าของ ไม่รวมไดเรกทอรีที่ติดตั้งและสร้างขึ้น และกู้คืนทั้งการประกาศแบบแบนและบริดจ์แพ็กเกจหลังจาก tsdown ล้าง dist การเปลี่ยนแปลงเอกสาร, เวิร์กโฟลว์, Plugin และรายการอื่นนอกกราฟนั้นสามารถนำสแนปช็อตการประกาศกลับมาใช้ใหม่ได้ ส่วนการเปลี่ยนแปลงซอร์สจะสร้างใหม่ก่อนเรียกใช้เกตการส่งออก
• การสร้างการประกาศแบบเต็มแบ่ง tsdown เป็นกลุ่ม AI, workspace-package และ unified แต่ละกลุ่มแคชเฉพาะการประกาศ จากนั้นยังคงสร้าง JavaScript รันไทม์ใหม่ก่อนกู้คืนการประกาศเหล่านั้น ดังนั้นการเปลี่ยนแปลงคอร์หรือ Plugin จะทำให้ใช้ไม่ได้เฉพาะกราฟ unified ขนาดใหญ่ ขณะที่การเปลี่ยนแปลง workspace-package จะทำให้กลุ่มการประกาศที่ขึ้นต่อกันทั้งหมดใช้ไม่ได้อย่างระมัดระวัง โดยทั่วไปการสร้างแบบเต็มสาธารณะใช้แคช Actions แบบเปลี่ยนแปลงไม่ได้ คีย์การกู้คืนแบบหยาบจะเป็นซีดให้การเปลี่ยนแปลงบางส่วน ลายนิ้วมือเนื้อหาต่อกลุ่มจะปฏิเสธข้อมูลล้าสมัย และโควตาแคชของ GitHub จะขับรุ่นเก่าออก ส่วนเลน Node 22 รายสัปดาห์จะเผยแพร่อาร์ติแฟกต์อายุ 14 วันหลังการทำงาน main สำเร็จ และกู้คืนเฉพาะอาร์ติแฟกต์ที่ข้อมูลระบุตัวผู้สร้างแบบเปลี่ยนแปลงไม่ได้แก้ไขไปยังเวิร์กโฟลว์นั้นบน main เพื่อหลีกเลี่ยงการหมุนเวียนโควตาโดยไม่อนุญาตให้โค้ด PR เขียนแคชที่ใช้ร่วมกัน การประกาศ Private-QA จะไม่ถูกเก็บในแคช Actions เนื่องจากเนมสเปซแคชไม่ใช่ขอบเขตการรักษาความลับ
• check-additional-* แบ่งรายการตัวป้องกันขอบเขตเสริม (scripts/run-additional-boundary-checks.mjs) เป็นชาร์ดที่ใช้พรอมต์หนักหนึ่งชาร์ด (check-additional-boundaries-a ซึ่งรวมการตรวจสอบการคลาดเคลื่อนของสแนปช็อตพรอมต์ Codex) และชาร์ดรวมหนึ่งชาร์ดสำหรับแถบที่เหลือ (check-additional-boundaries-bcd) โดยแต่ละชาร์ดเรียกใช้ตัวป้องกันอิสระพร้อมกันและพิมพ์เวลาต่อการตรวจสอบ งานคอมไพล์/คานารีของขอบเขตแพ็กเกจยังคงอยู่ด้วยกัน และสถาปัตยกรรมโทโพโลยีรันไทม์ทำงานแยกจากความครอบคลุมการเฝ้าดู Gateway ที่ฝังอยู่ใน build-artifacts
• บนรันเนอร์การสร้างแบบ self-hosted ขนาด 32-vCPU การเฝ้าดู Gateway, การทดสอบช่องทาง และชาร์ดขอบเขตการรองรับของคอร์จะเริ่มพร้อมกันภายใน build-artifacts หลังจากสร้าง dist/ และ dist-runtime/ แล้ว การทำงานสำรองบน GitHub-hosted จะยังคงเรียกใช้การเฝ้าดู Gateway แบบอนุกรม เพื่อไม่ให้การแข่งขันแย่งชิงคอร์ที่มีจำนวนน้อยกินเส้นตายความพร้อมของงาน

เมื่อได้รับอนุญาตแล้ว CI มาตรฐานบน Linux อนุญาตให้ทำงานทดสอบ Node พร้อมกันได้สูงสุด 28 งาน และ 12 งานสำหรับเลน fast/check ขนาดเล็กกว่า ส่วน Windows และ Android ยังคงอยู่ที่สองงานเนื่องจาก พูลรันเนอร์เหล่านั้นมีขนาดจำกัดกว่า แบตช์การกำหนดค่าทั้งชุดแบบกะทัดรัดทำงานโดยมีเวลาหมดเวลาแบตช์ 120 นาที ขณะที่กลุ่มรูปแบบ include ใช้งบประมาณงานที่มีขอบเขตเดียวกันร่วมกัน

Android CI เรียกใช้ทั้ง testPlayDebugUnitTest และ testThirdPartyDebugUnitTest แล้วสร้าง Play debug APK flavor ของบุคคลที่สามไม่มีชุดซอร์สหรือ manifest แยกต่างหาก เลนยูนิตทดสอบของ flavor นี้ยังคงคอมไพล์ flavor พร้อมแฟล็ก BuildConfig ของ SMS/call-log โดยหลีกเลี่ยงงานแพ็กเกจ debug APK ที่ซ้ำกันในการพุชทุกครั้งที่เกี่ยวข้องกับ Android งาน Gradle ปัจจุบันแต่ละงานมีดิสก์ถาวรที่ได้รับการป้องกันหนึ่งชุด งาน PR ใช้โคลนแบบใช้แล้วทิ้ง ขณะที่การทำงานที่ได้รับการป้องกันจะรีเฟรชรายการ Gradle แบบระบุตามเนื้อหาในตำแหน่งเดิม

คีย์ดิสก์ถาวรของ Blacksmith ถูกจำกัดโดยเจตนาตามมิติรันไทม์หรืองานที่รองรับเท่านั้น ไม่ใช้หมายเลข PR, คอมมิต, การทำงาน, บรานช์ หรือแฮชการขึ้นต่อกัน แคชการแปลงและคอมไพล์รันไทม์ใช้แคช Actions แทนดิสก์ถาวร เนื่องจากอาร์ไคฟ์แบบเปลี่ยนแปลงไม่ได้แสดงผลการกู้คืน/บันทึกที่ตรวจสอบได้ และหลีกเลี่ยงความล้มเหลวในการเลื่อนระดับสแนปช็อตแบบเปลี่ยนแปลงได้ หลังการย้ายเวอร์ชันคีย์ถาวร ให้เพิ่มเฉพาะข้อมูลระบุตัวตนของคีย์, สถาปัตยกรรม และภูมิภาคที่เลิกใช้แล้วอย่างแน่นอนลงใน .github/retired-sticky-disks.json, สั่งทำงาน Sticky Disk Cleanup จาก main ด้วยมิติและการยืนยันเดียวกัน, ตรวจสอบการลบ แล้วจึงนำรายการเหล่านั้นออก เวิร์กโฟลว์กำหนดเส้นทางข้อมูลระบุตัวตน ARM ไปยังรันเนอร์ ARM, ปฏิเสธความไม่ตรงกันของภูมิภาครันเนอร์, ใช้แอ็กชันลบคีย์แบบตรงกันทุกประการของ Blacksmith และไม่ลบแคชตัวสร้าง Docker หรือคำนำหน้าแบบไวลด์การ์ด แคชอาร์ไคฟ์ Actions ใช้ LRU และการขับออกเมื่อไม่มีการใช้งานตามปกติ

ชาร์ด check-dependencies เรียกใช้การตรวจสอบการขึ้นต่อกัน, ไฟล์ที่ไม่ได้ใช้ และการส่งออกที่ไม่ได้ใช้ในโค้ดใช้งานจริงด้วย Knip ตัวป้องกันไฟล์ที่ไม่ได้ใช้จะล้มเหลวเมื่อ PR เพิ่มไฟล์ที่ไม่ได้ใช้ใหม่ซึ่งยังไม่ผ่านการรีวิว หรือทิ้งรายการ allowlist ที่ล้าสมัยไว้ โดยยังคงรักษาพื้นผิว Plugin แบบไดนามิก, ที่สร้างขึ้น, การสร้าง, การทดสอบแบบ live และบริดจ์แพ็กเกจที่ตั้งใจไว้ ซึ่ง Knip ไม่สามารถแก้ไขแบบสแตติกได้ ตัวป้องกันการส่งออกที่ไม่ได้ใช้จะไม่รวมไฟล์สนับสนุนการทดสอบและล้มเหลวเมื่อพบการส่งออกของโค้ดใช้งานจริงที่ไม่ได้ใช้ทุกรายการ ผู้ใช้แบบไดนามิกที่ตั้งใจไว้ต้องถูกจำลองใน config/knip.config.ts เป้าหมายในอดีตจะเรียกใช้ตัวป้องกันการส่งออกเมื่อมีให้ใช้ และยังคงใช้วิธีสำรองตรวจหาโค้ดที่ไม่ทำงานแบบเดิมในกรณีอื่น

การส่งต่อกิจกรรม ClawSweeper

.github/workflows/clawsweeper-dispatch.yml เป็นบริดจ์ฝั่งเป้าหมายที่ส่งกิจกรรมจากที่เก็บ OpenClaw ไปยัง ClawSweeper โดยจะไม่ checkout หรือเรียกใช้โค้ด pull request ที่ไม่น่าเชื่อถือ เวิร์กโฟลว์สร้างโทเค็น GitHub App จาก CLAWSWEEPER_APP_PRIVATE_KEY แล้วส่งเพย์โหลด repository_dispatch แบบกะทัดรัดไปยัง openclaw/clawsweeper

เวิร์กโฟลว์มีสี่เลน:

• clawsweeper_item สำหรับคำขอรีวิว issue และ pull request ที่ระบุอย่างเจาะจง;
• clawsweeper_comment สำหรับคำสั่ง ClawSweeper ที่ระบุอย่างชัดเจนในความคิดเห็นของ issue;
• clawsweeper_commit_review สำหรับคำขอรีวิวระดับ commit ในการ push ไปยัง main;
• github_activity สำหรับกิจกรรมทั่วไปของ GitHub ที่เอเจนต์ ClawSweeper อาจตรวจสอบ

เลน github_activity ส่งต่อเฉพาะเมทาดาทาที่ปรับให้อยู่ในรูปแบบมาตรฐาน ได้แก่ ประเภทเหตุการณ์ การดำเนินการ ผู้กระทำ ที่เก็บ หมายเลขรายการ URL ชื่อเรื่อง สถานะ และข้อความตัดตอนสั้น ๆ ของความคิดเห็นหรือรีวิวเมื่อมี โดยตั้งใจหลีกเลี่ยงการส่งต่อเนื้อหา Webhook ทั้งหมด เวิร์กโฟลว์ฝั่งรับใน openclaw/clawsweeper คือ .github/workflows/github-activity.yml ซึ่งโพสต์เหตุการณ์ที่ปรับให้อยู่ในรูปแบบมาตรฐานไปยังฮุกของ OpenClaw Gateway สำหรับเอเจนต์ ClawSweeper

กิจกรรมทั่วไปมีไว้เพื่อการสังเกต ไม่ใช่การส่งโดยค่าเริ่มต้น เอเจนต์ ClawSweeper จะได้รับเป้าหมาย Discord ในพรอมป์ต์ และควรโพสต์ไปยัง #clawsweeper เฉพาะเมื่อเหตุการณ์นั้นผิดคาด ดำเนินการต่อได้ มีความเสี่ยง หรือมีประโยชน์ต่อการปฏิบัติงาน การเปิดและแก้ไขตามปกติ ความเคลื่อนไหวจากบอต สัญญาณรบกวนจาก Webhook ที่ซ้ำกัน และการรับส่งรีวิวตามปกติควรให้ผลลัพธ์เป็น NO_REPLY

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

การ dispatch ด้วยตนเอง

การ dispatch CI ด้วยตนเองเรียกใช้กราฟงานเดียวกับ CI ปกติ แต่บังคับเปิดทุกเลนตามขอบเขตที่ไม่ใช่ Android ได้แก่ shard ของ Linux Node, shard ของ Plugin ที่รวมมาให้, shard ของสัญญา Plugin และช่องทาง, ความเข้ากันได้กับ Node 22, check-*, check-additional-*, การตรวจสอบ smoke ของอาร์ติแฟกต์ที่ build แล้ว, การตรวจสอบเอกสาร, Python skills, Windows, macOS, การ build iOS และ i18n ของ Control UI/แอปเนทีฟ PR ต้นทางอัตโนมัติจะตรวจสอบรายการคงคลังการแยกข้อความเนทีฟและความปลอดภัยในการแปล Android/Apple โดยไม่กำหนดให้มีเอาต์พุตที่แปลแล้วหรือสร้างโดยแพลตฟอร์มใน PR เดียวกัน เวิร์กโฟลว์ Native App Locale Refresh แบบเรียงลำดับจะสร้างอาร์ติแฟกต์เหล่านั้นใหม่ใน PR แยกต่างหากหนึ่งรายการ และเปิดใช้การผสานอัตโนมัติที่ exact-head หลังจากการตรวจสอบที่จำเป็นผ่าน ความสอดคล้องครบถ้วนของเนทีฟยังคงเป็นเงื่อนไขบังคับสำหรับ PR อาร์ติแฟกต์ที่สร้างขึ้น, CI แบบดำเนินการด้วยตนเอง, Full Release Validation และการเตรียมรีลีส ความสอดคล้องของโลแคล Control UI ยังคงเป็นเพียงคำแนะนำในการทำงานของ PR อัตโนมัติและ main และเป็นเงื่อนไขบังคับใน CI แบบดำเนินการด้วยตนเอง/รีลีส การ dispatch CI ด้วยตนเองแบบสแตนด์อโลนจะเรียกใช้ Android เฉพาะเมื่อมี include_android=true (อินพุต release_gate ก็บังคับ Android เช่นกัน); เวิร์กโฟลว์ครอบคลุมรีลีสฉบับเต็มจะเปิดใช้ Android โดยส่ง include_android=true การตรวจสอบแบบสแตติกก่อนรีลีสของ Plugin, shard เฉพาะรีลีส agentic-plugins, การกวาดตรวจส่วนขยายทั้งชุด และเลน Docker ก่อนรีลีสของ Plugin ไม่รวมอยู่ใน CI ชุดทดสอบก่อนรีลีสของ Docker จะทำงานเฉพาะเมื่อ Full Release Validation dispatch เวิร์กโฟลว์ Plugin Prerelease แยกต่างหากโดยเปิดใช้เกตการตรวจสอบรีลีส

การตรวจสอบจำนวนบรรทัดสูงสุดของ PR จะหา baseline จาก merge tree สังเคราะห์ที่ checkout แล้ว และตรวจสอบ parent ของ head เทียบกับ head ของเหตุการณ์ การทำงานด้วยตนเองใช้กลุ่ม concurrency ที่ไม่ซ้ำกัน เพื่อไม่ให้ชุดทดสอบฉบับเต็มของ release candidate ถูกยกเลิกโดยการ push หรือการทำงานของ PR อื่นบน ref เดียวกัน อินพุต target_ref ซึ่งเป็นตัวเลือกช่วยให้ผู้เรียกที่เชื่อถือได้เรียกใช้กราฟนั้นกับ branch, tag หรือ SHA ของ commit แบบเต็ม โดยใช้ไฟล์เวิร์กโฟลว์จาก ref ที่เลือกสำหรับการ dispatch; baseline ของจำนวนบรรทัดสูงสุดจะถูกเปรียบเทียบกับ merge base ของเป้าหมายเทียบกับ head ของ branch เริ่มต้นที่ resolve สำหรับการทำงานนั้น อินพุต release_gate เป็นทางเลือกสำรองแบบ exact-SHA สำหรับผู้ดูแลเมื่อ CI ของ PR ติดขัดจากข้อจำกัดด้านความจุ โดยกำหนดให้ target_ref เป็น SHA ของ commit แบบเต็มที่ตรงกับ head ของ branch ที่ dispatch และให้ pull_request_number ระบุ PR ที่เปิดอยู่ซึ่งมีการตรวจสอบ merge tree

gh workflow run ci.yml --ref release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=truegh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

เส้นทาง extended-stable รายเดือนเฉพาะ npm เป็นข้อยกเว้น: ให้ dispatch ทั้ง preflight OpenClaw NPM Release และ Full Release Validation จาก branch extended-stable/YYYY.M.33 ที่ตรงกันทุกประการ เก็บรักษา ID การทำงานของทั้งสองรายการ และส่ง ID ทั้งสองไปยัง การทำงานเผยแพร่ npm โดยตรง ดูคำสั่ง ข้อกำหนดด้านข้อมูลประจำตัวที่ตรงกันทุกประการ การอ่านค่ากลับจากรีจิสทรี และกระบวนการ ซ่อมแซม selector ได้ที่ การเผยแพร่ extended-stable รายเดือนเฉพาะ npm เส้นทางนี้จะไม่ dispatch การเผยแพร่ Plugin, macOS, Windows, GitHub Release, dist-tag ส่วนตัว หรือแพลตฟอร์มอื่น

Runner

งบประมาณการลงทะเบียน Runner

บัคเก็ตการลงทะเบียน Runner ของ GitHub ปัจจุบันสำหรับ OpenClaw รายงานการลงทะเบียน Runner แบบ self-hosted 10,000 ครั้งต่อ 5 นาทีใน ghx api rate_limit ให้ตรวจสอบ actions_runner_registration อีกครั้งก่อนการปรับแต่งแต่ละรอบ เพราะ GitHub อาจเปลี่ยน บัคเก็ตนี้ ขีดจำกัดนี้ใช้ร่วมกันโดยการลงทะเบียน Runner ของ Blacksmith ทั้งหมดใน องค์กร openclaw ดังนั้นการเพิ่มการติดตั้ง Blacksmith อีกรายการจะไม่เพิ่ม บัคเก็ตใหม่

ให้ถือว่าป้ายกำกับ Blacksmith เป็นทรัพยากรที่มีจำกัดสำหรับการควบคุมการทำงานเป็นระลอก งานที่ ทำเพียงกำหนดเส้นทาง แจ้งเตือน สรุป เลือก shard หรือเรียกใช้การสแกน CodeQL ระยะสั้นควร คงอยู่บน Runner ที่โฮสต์โดย GitHub เว้นแต่จะมีความจำเป็นเฉพาะ Blacksmith ที่วัดผลแล้ว เมทริกซ์ Blacksmith ใหม่ทุกชุด, max-parallel ที่ใหญ่ขึ้น หรือเวิร์กโฟลว์ ความถี่สูง ต้องแสดงจำนวนการลงทะเบียนในกรณีเลวร้ายที่สุด และรักษาเป้าหมายระดับองค์กร ไว้ต่ำกว่าประมาณ 60% ของบัคเก็ตที่ใช้งานอยู่ สำหรับบัคเก็ตปัจจุบันที่รองรับการลงทะเบียน 10,000 ครั้ง นั่นหมายถึงเป้าหมายการปฏิบัติงานที่ 6,000 การลงทะเบียน โดยเหลือพื้นที่สำรองสำหรับ ที่เก็บที่ทำงานพร้อมกัน การลองใหม่ และการซ้อนทับของระลอกงาน

แผน PR แบบ changed-target ลดระลอกการทดสอบ Node ทั่วไปจากการลงทะเบียน Blacksmith 14 ครั้งเหลือหนึ่งครั้ง PR ที่มีความเสี่ยงกว้างยังคงใช้ทางเลือกสำรองแบบกะทัดรัดที่มีการลงทะเบียน 14 ครั้ง ดังนั้นกรณีเลวร้ายที่สุดจึงไม่เพิ่มขึ้น

CI ของที่เก็บ canonical ยังคงใช้ Blacksmith เป็นเส้นทาง Runner เริ่มต้นสำหรับการ push และการทำงานของ pull request ตามปกติ workflow_dispatch และการทำงานในที่เก็บที่ไม่ใช่ canonical จะใช้ Runner ที่โฮสต์โดย GitHub แต่การทำงาน canonical ตามปกติยังไม่ตรวจสอบสภาพคิวของ Blacksmith หรือเปลี่ยนไปใช้ป้ายกำกับที่โฮสต์โดย GitHub โดยอัตโนมัติเมื่อ Blacksmith ไม่พร้อมใช้งาน

คำสั่งเทียบเท่าสำหรับเครื่องภายใน

pnpm changed:lanes                            # ตรวจสอบตัวจำแนกเลนที่เปลี่ยนแปลงในเครื่องสำหรับ origin/main...HEADpnpm check:changed                            # เกตตรวจสอบอัจฉริยะในเครื่อง: การจัดรูปแบบ/typecheck/lint/guard ที่เปลี่ยนแปลงตามเลนขอบเขตpnpm check                                    # เกตภายในเครื่องแบบรวดเร็ว: tsgo สำหรับ prod + lint แบบแบ่ง shard + guard แบบรวดเร็วที่ทำงานขนานกันpnpm check:test-typespnpm check:timed                              # เกตเดียวกันพร้อมเวลาในแต่ละขั้นpnpm build:strict-smokepnpm check:architecturepnpm test:gateway:watch-regressionOPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.tspnpm test                                     # การทดสอบ vitestpnpm test:changed                             # เป้าหมาย Vitest ที่เปลี่ยนแปลงแบบอัจฉริยะและประหยัดpnpm test:ui                                  # ชุดทดสอบ unit/เบราว์เซอร์ของ Control UIpnpm ui:i18n:check                            # ความสอดคล้องของโลแคล Control UI ที่สร้างขึ้น (เกตรีลีส)pnpm native:i18n:baseline                     # อัปเดตรายการคงคลังการแยกข้อความเนทีฟที่ต้นทางเป็นเจ้าของpnpm native:i18n:verify                       # รายการคงคลังต้นทาง + ความปลอดภัยในการแปล Android/Applepnpm native:i18n:check                        # ความสอดคล้องอย่างเข้มงวดของงานแปล/สิ่งที่แพลตฟอร์มสร้างขึ้น (เกตรีลีส)pnpm test:channelspnpm test:contracts:channelspnpm check:docs                               # รูปแบบเอกสาร + lint + ลิงก์เสียpnpm build                                    # build dist เมื่อการตรวจสอบอาร์ติแฟกต์/smoke ของ CI มีความสำคัญpnpm ios:build                                # สร้างและ build โปรเจกต์แอป iOSpnpm ci:timings                               # สรุปการทำงาน CI จากการ push ไปยัง origin/main ล่าสุดpnpm ci:timings:recent                        # เปรียบเทียบการทำงาน CI ของ main ที่สำเร็จล่าสุดnode scripts/ci-run-timings.mjs <run-id>      # สรุปเวลารวม เวลารอคิว และงานที่ช้าที่สุดnode scripts/ci-run-timings.mjs --latest-main # ไม่รวมสัญญาณรบกวนจาก issue/ความคิดเห็น และเลือก CI จากการ push ไปยัง origin/mainnode scripts/ci-run-timings.mjs --recent 10   # เปรียบเทียบการทำงาน CI ของ main ที่สำเร็จล่าสุดpnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.jsonpnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.jsonpnpm test:startup:memorypnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.jsonpnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

ประสิทธิภาพของ OpenClaw

OpenClaw Performance คือเวิร์กโฟลว์ประสิทธิภาพของผลิตภัณฑ์/รันไทม์ โดยทำงานทุกวันบน main และสามารถ dispatch ด้วยตนเองได้:

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=truegh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

โดยปกติการสั่งรันด้วยตนเองจะวัดประสิทธิภาพของ ref ของเวิร์กโฟลว์ ตั้งค่า target_ref เพื่อวัดประสิทธิภาพของแท็กรุ่นเผยแพร่หรือสาขาอื่นด้วยการใช้งานเวิร์กโฟลว์ปัจจุบัน พาธรายงานที่เผยแพร่และตัวชี้ล่าสุดจะกำหนดคีย์ตาม ref ที่ทดสอบ และแต่ละ index.md จะบันทึก ref/SHA ที่ทดสอบ, ref/SHA ของเวิร์กโฟลว์, ref ของ Kova, โปรไฟล์, โหมดการยืนยันตัวตนของเลน, โมเดล, จำนวนครั้งที่ทำซ้ำ และตัวกรองสถานการณ์

เวิร์กโฟลว์ติดตั้ง OCM จากรุ่นเผยแพร่ที่ตรึงไว้ และติดตั้ง Kova จาก openclaw/Kova ตามอินพุต kova_ref ที่ตรึงไว้ จากนั้นรันสามเลน:

• mock-provider: สถานการณ์วินิจฉัยของ Kova กับรันไทม์ที่บิลด์ภายในเครื่อง โดยใช้การยืนยันตัวตนจำลองที่เข้ากันได้กับ OpenAI และให้ผลลัพธ์แบบกำหนดแน่นอน
• mock-deep-profile: การทำโปรไฟล์ CPU/ฮีป/เทรซสำหรับจุดคอขวดในการเริ่มต้น, Gateway และรอบการทำงานของเอเจนต์ รันตามกำหนดเวลา หรือเมื่อสั่งรันด้วย deep_profile=true
• live-openai-candidate: รอบการทำงานจริงของเอเจนต์ OpenAI openai/gpt-5.6-luna ซึ่งจะข้ามเมื่อ OPENAI_API_KEY ไม่พร้อมใช้งาน รันตามกำหนดเวลา หรือเมื่อสั่งรันด้วย live_openai_candidate=true

เลนผู้ให้บริการจำลองยังรันโพรบซอร์สแบบเนทีฟของ OpenClaw หลังจาก Kova ทำงานผ่านแล้ว ได้แก่ เวลาเริ่มทำงานและหน่วยความจำของ Gateway ในกรณีเริ่มต้นแบบค่าเริ่มต้น, ข้ามช่องทาง, ฮุกภายใน และ Plugin จำนวนห้าสิบรายการ; RSS จากการนำเข้า Plugin ที่รวมมาให้, ลูปกล่าวทักทาย channel-chat-baseline ด้วย OpenAI จำลองซ้ำหลายครั้ง, คำสั่งเริ่มต้น CLI กับ Gateway ที่บูตแล้ว และโพรบประสิทธิภาพ smoke ของสถานะ SQLite เมื่อมีรายงานซอร์สของผู้ให้บริการจำลองที่เผยแพร่ก่อนหน้าสำหรับ ref ที่ทดสอบ สรุปซอร์สจะเปรียบเทียบค่า RSS และฮีปปัจจุบันกับค่าฐานนั้น และทำเครื่องหมายการเพิ่มขึ้นอย่างมากของ RSS เป็น watch สรุปโพรบซอร์สแบบ Markdown อยู่ที่ source/index.md ในชุดรายงาน โดยมี JSON ดิบอยู่ข้างกัน

ทุกเลนจะอัปโหลดอาร์ติแฟกต์ GitHub ฉบับสมบูรณ์ รวมถึงชุด CPU, ฮีป, เทรซ และชุดวินิจฉัยที่บีบอัด งานเผยแพร่แยกต่างหากจะดาวน์โหลดและตรวจสอบอาร์ติแฟกต์เหล่านั้น จากนั้นสร้างโทเค็น GitHub App ของ ClawSweeper ที่มีอายุสั้นและจำกัดขอบเขตเฉพาะเนื้อหา openclaw/clawgrit-reports แล้วส่งโทเค็นนั้นให้เฉพาะขั้นตอน Git push เท่านั้น งานจะคอมมิต report.json, report.md, index.md, อาร์ติแฟกต์โพรบซอร์ส และเมทาดาทา/ผลรวมตรวจสอบของชุดไว้ภายใต้ openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/; ส่วนคลังวินิจฉัยฉบับเต็มจะยังคงอยู่ในอาร์ติแฟกต์ Actions ที่เชื่อมโยง งานเผยแพร่จะปฏิเสธไฟล์รายงานใดก็ตามที่มีขนาดเกิน 50 MB ก่อนพยายามพุช ตัวชี้ ref ที่ทดสอบปัจจุบันคือ openclaw-performance/<tested-ref>/latest-<lane>.json การรันตามกำหนดเวลาและการสั่งรัน profile=release จะล้มเหลวหากการสร้างโทเค็นแอปหรือการเผยแพร่รายงานล้มเหลว การสั่งรันด้วยตนเองที่ไม่ใช่รุ่นเผยแพร่จะถือว่าการเผยแพร่เป็นเพียงคำแนะนำ และเก็บอาร์ติแฟกต์ GitHub ไว้เมื่อการยืนยันตัวตนหรือการเผยแพร่ล้มเหลว ค่าฐานซอร์สก่อนหน้าจะถูกดึงแบบไม่ระบุตัวตนจากที่เก็บรายงานสาธารณะ ดังนั้นการดึงค่าฐานสำเร็จจึงไม่ได้พิสูจน์ว่าการยืนยันตัวตนของผู้เผยแพร่สำเร็จ

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

Full Release Validation คือเวิร์กโฟลว์ครอบคลุมแบบสั่งรันด้วยตนเองสำหรับ "รันทุกอย่างก่อนเผยแพร่รุ่น" โดยรับสาขา แท็ก หรือ SHA แบบเต็มของคอมมิต สั่งรันเวิร์กโฟลว์ CI แบบกำหนดเองด้วยเป้าหมายนั้น (รวมถึง Android) สั่งรัน Plugin Prerelease สำหรับหลักฐานเฉพาะรุ่นเผยแพร่ของ Plugin/แพ็กเกจ/สแตติก/Docker สั่งรัน OpenClaw Performance กับ SHA เป้าหมาย และสั่งรัน OpenClaw Release Checks สำหรับ smoke การติดตั้ง, การยอมรับแพ็กเกจ, การตรวจสอบแพ็กเกจข้ามระบบปฏิบัติการ, ความสอดคล้องของ QA Lab, Matrix, Telegram และเลน Discord, WhatsApp และ Slack ที่มีเกต (การเรนเดอร์ตารางคะแนนวุฒิภาวะแบบคำแนะนำเปิดใช้ได้ด้วย run_maturity_scorecard) โปรไฟล์เสถียรและเต็มจะรวมความครอบคลุม live/E2E แบบละเอียดครบถ้วนและการทดสอบแช่เส้นทางเผยแพร่ Docker เสมอ ส่วนโปรไฟล์เบตาสามารถเลือกเข้าร่วมด้วย run_release_soak=true E2E ของ Telegram สำหรับแพ็กเกจมาตรฐานจะรันภายใน Package Acceptance ดังนั้นตัวเลือกฉบับเต็มจึงไม่เริ่มตัวสำรวจแบบ live ซ้ำ หลังเผยแพร่ ให้ส่ง release_package_spec เพื่อนำแพ็กเกจ npm ที่เผยแพร่แล้วกลับมาใช้ซ้ำในการตรวจสอบรุ่นเผยแพร่, Package Acceptance, Docker, การตรวจสอบข้ามระบบปฏิบัติการ และ Telegram โดยไม่ต้องบิลด์ใหม่ ใช้ npm_telegram_package_spec เฉพาะสำหรับการรัน Telegram ซ้ำแบบเจาะจงกับแพ็กเกจที่เผยแพร่แล้ว เลนแพ็กเกจ live ของ Plugin Codex ใช้สถานะที่เลือกเดียวกันโดยค่าเริ่มต้น: release_package_spec=openclaw@<tag> ที่เผยแพร่แล้วจะกำหนด codex_plugin_spec=npm:@openclaw/codex@<tag> ส่วนการรัน SHA/อาร์ติแฟกต์จะแพ็ก extensions/codex จาก ref ที่เลือก ตั้งค่า codex_plugin_spec อย่างชัดเจนสำหรับซอร์ส Plugin แบบกำหนดเอง เช่นข้อกำหนด npm:, npm-pack: หรือ git: หลักฐานเอเจนต์แบบ live จะส่งความคืบหน้าที่มองเห็นได้ ดำเนินต่อด้วยการอ่านเวิร์กสเปซแบบสุ่มและการเขียนอาร์ติแฟกต์อย่างแม่นยำ จากนั้นส่งสถานะเสร็จสมบูรณ์

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

OpenClaw Release Publish คือเวิร์กโฟลว์เผยแพร่ที่เปลี่ยนแปลงสถานะและสั่งรันด้วยตนเอง สั่งรัน การเผยแพร่เบตาและเสถียรตามปกติจาก main ที่เชื่อถือได้หลังจากมีแท็กรุ่นเผยแพร่ และหลังจากการตรวจสอบเบื้องต้นของ OpenClaw npm สำเร็จแล้ว (การตรวจสอบเบื้องต้นจะรัน pnpm plugins:sync:check เป็นหนึ่งในการตรวจสอบ) แท็กยังคงเลือก คอมมิตรุ่นเผยแพร่ที่แน่นอน รวมถึงคอมมิตบน release/YYYY.M.PATCH; การเผยแพร่ Tideclaw alpha ยังคงใช้สาขา alpha ที่ตรงกัน โดยต้องมี preflight_run_id ที่บันทึกไว้ รวมถึง full_release_validation_run_id ที่สำเร็จและ full_release_validation_run_attempt ที่ตรงกันอย่างแม่นยำ จากนั้นสั่งรัน Plugin NPM Release สำหรับ แพ็กเกจ Plugin ทั้งหมดที่เผยแพร่ได้ สั่งรัน Plugin ClawHub Release สำหรับ SHA รุ่นเผยแพร่เดียวกัน และหลังจากนั้นเท่านั้นจึงสั่งรัน OpenClaw NPM Release การเผยแพร่แบบเสถียรยัง ต้องมี windows_node_tag ที่ตรงกันอย่างแม่นยำ เวิร์กโฟลว์จะตรวจสอบรุ่นเผยแพร่ซอร์ส Windows และเปรียบเทียบตัวติดตั้ง x64/ARM64 กับอินพุต windows_node_installer_digests ที่ตัวเลือกได้อนุมัติแล้วก่อนเริ่มงานย่อยสำหรับเผยแพร่ใดๆ จากนั้นจึงเลื่อนสถานะ และตรวจสอบไดเจสต์ตัวติดตั้งที่ตรึงไว้ชุดเดียวกัน รวมทั้งสัญญาของอาร์ติแฟกต์คู่กันและผลรวมตรวจสอบที่ตรงกัน ก่อนเผยแพร่ฉบับร่างรุ่นเผยแพร่ GitHub การแก้ไขเฉพาะ Plugin แบบเจาะจงใช้ plugin_publish_scope=selected พร้อม รายการแพ็กเกจที่ไม่ว่างเปล่า การรัน all-publishable เฉพาะ Plugin ต้องใช้หลักฐาน การตรวจสอบเบื้องต้น npm ที่เปลี่ยนแปลงไม่ได้และการตรวจสอบความถูกต้องของรุ่นเผยแพร่แบบเต็มเช่นเดียวกับการเผยแพร่แกนหลัก

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

สำหรับหลักฐานคอมมิตที่ตรึงไว้บนสาขาที่เปลี่ยนแปลงอย่างรวดเร็ว ให้ใช้ตัวช่วยแทน gh workflow run ... --ref main -f ref=<sha>:

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

ref สำหรับสั่งรันเวิร์กโฟลว์ GitHub ต้องเป็น branch หรือ tag ไม่ใช่ commit SHA ดิบ ตัวช่วยจะ push branch ชั่วคราว release-ci/<sha>-... ที่ workflow SHA main ที่เชื่อถือได้ ส่ง target SHA ที่ร้องขอผ่าน input ref ของเวิร์กโฟลว์ ใช้หลักฐาน exact-target แบบเข้มงวดซ้ำเมื่อมีอยู่ ตรวจสอบว่า headSha ของเวิร์กโฟลว์ลูกทุกรายการตรงกับ workflow SHA ที่เชื่อถือได้ และลบ branch ชั่วคราวเมื่อการรันเสร็จสิ้น ส่ง -f reuse_evidence=false เพื่อบังคับให้ตรวจสอบความถูกต้องใหม่ ตัวตรวจสอบแบบครอบคลุมจะล้มเหลวด้วยหากเวิร์กโฟลว์ลูกใดรันด้วย workflow SHA ที่แตกต่างกัน

release_profile ควบคุมขอบเขต live/provider ที่ส่งไปยังการตรวจสอบ release เวิร์กโฟลว์ release แบบดำเนินการด้วยตนเองมีค่าเริ่มต้นเป็น stable; ใช้ full เฉพาะเมื่อต้องการเมทริกซ์ provider/media แบบ advisory ที่ครอบคลุมโดยตั้งใจเท่านั้น การตรวจสอบ stable และ full release จะรันการทดสอบต่อเนื่องตามเส้นทาง release แบบ live/E2E และ Docker อย่างครบถ้วนเสมอ ส่วนโปรไฟล์ beta สามารถเลือกเปิดใช้ได้ด้วย run_release_soak=true

• beta คง lane ที่สำคัญต่อ release ของ OpenAI/core ซึ่งเร็วที่สุดไว้
• stable เพิ่มชุด provider/backend สำหรับ stable
• full รันเมทริกซ์ provider/media แบบ advisory ที่ครอบคลุม

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

สำหรับการกู้คืน ทั้ง Full Release Validation และ OpenClaw Release Checks รองรับ rerun_group ใช้ all สำหรับ release candidate, ci สำหรับเฉพาะรายการลูก full CI ปกติ, plugin-prerelease สำหรับเฉพาะรายการลูก prerelease ของ plugin, performance สำหรับเฉพาะรายการลูก OpenClaw Performance, release-checks สำหรับรายการลูก release ทั้งหมด หรือใช้กลุ่มที่แคบกว่า ได้แก่ install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live หรือ npm-telegram บนตัวครอบคลุม วิธีนี้จำกัดขอบเขตการรันซ้ำของกล่อง release ที่ล้มเหลวหลังการแก้ไขเฉพาะจุด สำหรับ lane ข้าม OS ที่ล้มเหลวหนึ่งรายการ ให้ใช้ rerun_group=cross-os ร่วมกับ cross_os_suite_filter เช่น windows/packaged-upgrade; คำสั่งข้าม OS ที่ใช้เวลานานจะแสดงบรรทัด Heartbeat และสรุปการอัปเกรดแพ็กเกจจะรวมเวลาของแต่ละระยะ lane QA ของ Matrix และ Telegram ที่เลือกไว้จะบล็อกการตรวจสอบ release ปกติ เช่นเดียวกับ gate มาตรฐานสำหรับความครอบคลุมของเครื่องมือ runtime ส่วนความสอดคล้องของ QA ความสอดคล้องของ runtime และ lane live ของ Discord, WhatsApp และ Slack ที่มี gate เป็นเพียง advisory

OpenClaw Release Checks ใช้ ref ของเวิร์กโฟลว์ที่เชื่อถือได้เพื่อ resolve ref ที่เลือกเป็น tarball release-package-under-test เพียงครั้งเดียว จากนั้นส่ง artifact ดังกล่าวไปยังการตรวจสอบข้าม OS และ Package Acceptance รวมถึงเวิร์กโฟลว์ Docker ตามเส้นทาง release แบบ live/E2E เมื่อมีการรันความครอบคลุมแบบ soak วิธีนี้ทำให้ไบต์ของแพ็กเกจสอดคล้องกันในกล่อง release ต่าง ๆ และหลีกเลี่ยงการแพ็ก candidate เดียวกันซ้ำใน job ลูกหลายรายการ สำหรับ lane live ของ Codex npm-plugin การตรวจสอบ release จะส่ง spec ของ plugin ที่เผยแพร่แล้วซึ่งตรงกันและได้มาจาก release_package_spec หรือส่ง codex_plugin_spec ที่ผู้ปฏิบัติงานระบุ หรือเว้น input ว่างไว้เพื่อให้สคริปต์ Docker แพ็ก Codex plugin จาก checkout ที่เลือก

การรัน Full Release Validation ที่ซ้ำกันสำหรับ ref=main และ rerun_group=all จะแทนที่ตัวครอบคลุมรายการเก่า ตัวเฝ้าติดตามของ parent จะยกเลิกเวิร์กโฟลว์ลูกทุกรายการที่สั่งรันไปแล้วเมื่อ parent ถูกยกเลิก เพื่อให้การตรวจสอบ main ที่ใหม่กว่าไม่ต้องรอหลังการรันตรวจสอบ release เก่าที่ใช้เวลาสองชั่วโมง การตรวจสอบ branch/tag ของ release และกลุ่มการรันซ้ำเฉพาะจุดจะคง cancel-in-progress: false ไว้

shard แบบ Live และ E2E

รายการลูก live/E2E ของ release ยังคงความครอบคลุม native pnpm test:live ที่กว้าง แต่รันเป็น shard ที่มีชื่อผ่าน scripts/test-live-shard.mjs แทน job แบบลำดับเดียว:

• native-live-src-agents และ native-live-src-agents-zai-coding
• native-live-src-gateway-core
• job native-live-src-gateway-profiles ที่กรองตาม provider
• native-live-src-gateway-backends
• native-live-src-infra
• native-live-test
• native-live-extensions-a-k
• native-live-extensions-l-n
• native-live-extensions-moonshot
• native-live-extensions-openai
• native-live-extensions-o-z-other
• native-live-extensions-xai
• แยก shard เสียง/วิดีโอของสื่อและ shard เพลงที่กรองตาม provider

วิธีนี้คงความครอบคลุมของไฟล์เดิมไว้ พร้อมทำให้ความล้มเหลวของ provider แบบ live ที่ช้ารันซ้ำและวินิจฉัยได้ง่ายขึ้น ชื่อ shard แบบรวม native-live-src-gateway, native-live-extensions-o-z, native-live-extensions-media และ native-live-extensions-media-music ยังคงใช้ได้สำหรับการรันซ้ำครั้งเดียวด้วยตนเอง

shard สื่อแบบ native live รันใน ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04 ซึ่งสร้างโดยเวิร์กโฟลว์ Live Media Runner Image image ดังกล่าวติดตั้ง ffmpeg และ ffprobe ไว้ล่วงหน้า; job สื่อจะตรวจสอบเฉพาะ binary ก่อนการตั้งค่า ให้ชุดทดสอบ live ที่ใช้ Docker backend รันบน runner Blacksmith ปกติ เพราะ container job ไม่เหมาะสำหรับเปิดการทดสอบ Docker แบบซ้อนกัน

ชาร์ดโมเดล/แบ็กเอนด์แบบใช้งานจริงที่รองรับด้วย Docker ใช้อิมเมจ ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions> ที่ใช้ร่วมกันแยกต่างหากต่อคอมมิตที่เลือก เวิร์กโฟลว์รีลีสแบบใช้งานจริงจะสร้างและพุชอิมเมจนั้นหนึ่งครั้ง จากนั้นชาร์ดโมเดลแบบใช้งานจริงบน Docker, Gateway ที่แบ่งชาร์ดตามผู้ให้บริการ, แบ็กเอนด์ CLI, การผูก ACP และชุดทดสอบ Codex จะทำงานด้วย OPENCLAW_SKIP_DOCKER_BUILD=1 ชาร์ด Gateway Docker มีขีดจำกัด timeout ระดับสคริปต์ที่กำหนดไว้อย่างชัดเจนและต่ำกว่าไทม์เอาต์ของงานในเวิร์กโฟลว์ เพื่อให้คอนเทนเนอร์ที่ค้างหรือเส้นทางการล้างข้อมูลที่ติดขัดล้มเหลวอย่างรวดเร็วแทนที่จะใช้โควตาเวลาของการตรวจสอบรีลีสจนหมด หากชาร์ดเหล่านั้นสร้างเป้าหมาย Docker จากซอร์สทั้งหมดใหม่โดยอิสระ แสดงว่าการเรียกใช้รีลีสกำหนดค่าผิดและจะเสียเวลาจริงไปกับการสร้างอิมเมจซ้ำ

การยอมรับแพ็กเกจ

ใช้ Package Acceptance เมื่อคำถามคือ "แพ็กเกจ OpenClaw ที่ติดตั้งได้นี้ทำงานเป็นผลิตภัณฑ์ได้หรือไม่" ซึ่งแตกต่างจาก CI ปกติ: CI ปกติตรวจสอบความถูกต้องของแผนผังซอร์ส ขณะที่การยอมรับแพ็กเกจตรวจสอบ tarball เดียวผ่านชุดทดสอบ Docker E2E เดียวกับที่ผู้ใช้ใช้งานหลังติดตั้งหรืออัปเดต

งาน

1. resolve_package เช็กเอาต์ workflow_ref, ระบุแพ็กเกจที่เป็นตัวเลือกหนึ่งรายการ, เขียน .artifacts/docker-e2e-package/openclaw-current.tgz, เขียน .artifacts/docker-e2e-package/package-candidate.json, อัปโหลดทั้งสองเป็นอาร์ติแฟกต์ package-under-test และพิมพ์ซอร์ส, อ้างอิงเวิร์กโฟลว์, อ้างอิงแพ็กเกจ, เวอร์ชัน, SHA-256 และโปรไฟล์ในสรุปขั้นตอนของ GitHub
2. package_integrity ดาวน์โหลดอาร์ติแฟกต์ package-under-test และบังคับใช้สัญญา tarball ของแพ็กเกจสาธารณะด้วย scripts/check-openclaw-package-tarball.mjs
3. docker_acceptance เรียก openclaw-live-and-e2e-checks-reusable.yml ด้วย SHA ซอร์สของแพ็กเกจที่ระบุได้ (โดยใช้ workflow_ref เป็นทางเลือกสำรอง) และ package_artifact_name=package-under-test เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้จะดาวน์โหลดอาร์ติแฟกต์นั้น ตรวจสอบรายการภายใน tarball เตรียมอิมเมจ Docker ตามไดเจสต์ของแพ็กเกจเมื่อจำเป็น และเรียกใช้เลน Docker ที่เลือกกับแพ็กเกจนั้นแทนการแพ็กเช็กเอาต์ของเวิร์กโฟลว์ เมื่อโปรไฟล์เลือก docker_lanes แบบเจาะจงหลายรายการ เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้จะเตรียมแพ็กเกจและอิมเมจที่ใช้ร่วมกันหนึ่งครั้ง จากนั้นกระจายเลนเหล่านั้นเป็นงาน Docker แบบเจาะจงที่ทำงานขนานกันพร้อมอาร์ติแฟกต์เฉพาะ
4. package_telegram เลือกเรียก NPM Telegram Beta E2E ได้ งานนี้ทำงานเมื่อ telegram_mode ไม่ใช่ none และติดตั้งอาร์ติแฟกต์ package-under-test เดียวกันเมื่อการยอมรับแพ็กเกจระบุอาร์ติแฟกต์ได้ ส่วนการสั่งงาน Telegram แบบสแตนด์อโลนยังคงติดตั้งข้อกำหนด npm ที่เผยแพร่แล้วได้
5. summary ทำให้เวิร์กโฟลว์ล้มเหลวหากการระบุแพ็กเกจ ความสมบูรณ์ การยอมรับบน Docker หรือเลน Telegram ที่เป็นตัวเลือกล้มเหลว อินพุต advisory จะลดระดับความล้มเหลวของการยอมรับให้เป็นคำเตือนสำหรับผู้เรียกที่ใช้เป็นคำแนะนำ

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

• source=npm ยอมรับเฉพาะ openclaw@extended-stable, openclaw@beta, openclaw@latest หรือเวอร์ชันรีลีส OpenClaw ที่ระบุแน่นอน เช่น [email protected] ใช้สำหรับการยอมรับเวอร์ชัน extended-stable, ก่อนรีลีส หรือ stable ที่เผยแพร่แล้ว
• source=ref แพ็กบรานช์ แท็ก หรือ SHA คอมมิตแบบเต็มของ package_ref ที่เชื่อถือได้ ตัวระบุจะดึงบรานช์/แท็ก OpenClaw ตรวจสอบว่าคอมมิตที่เลือกเข้าถึงได้จากประวัติบรานช์ของรีโพซิทอรีหรือแท็กรีลีส ติดตั้งดีเพนเดนซีใน worktree ที่แยกออกมา และแพ็กด้วย scripts/package-openclaw-for-docker.mjs
• source=url ดาวน์โหลด .tgz ผ่าน HTTPS สาธารณะ โดยต้องระบุ package_sha256 เส้นทางนี้ปฏิเสธข้อมูลรับรองใน URL, พอร์ต HTTPS ที่ไม่ใช่ค่าเริ่มต้น, ชื่อโฮสต์หรือ IP ที่แก้ชื่อแล้วซึ่งเป็นแบบส่วนตัว/ภายใน/ใช้งานเฉพาะ และการเปลี่ยนเส้นทางที่อยู่นอกนโยบายความปลอดภัยสาธารณะเดียวกัน
• source=trusted-url ดาวน์โหลด .tgz ผ่าน HTTPS จากนโยบายแหล่งที่มาที่เชื่อถือได้ซึ่งระบุชื่อไว้ใน .github/package-trusted-sources.json โดยต้องระบุ package_sha256 และ trusted_source_id ใช้เฉพาะกับมิเรอร์ระดับองค์กรหรือรีโพซิทอรีแพ็กเกจส่วนตัวที่ผู้ดูแลเป็นเจ้าของ ซึ่งต้องกำหนดค่าโฮสต์ พอร์ต คำนำหน้าพาธ โฮสต์สำหรับเปลี่ยนเส้นทาง หรือการแก้ชื่อเครือข่ายส่วนตัว หากนโยบายประกาศการยืนยันตัวตนแบบ bearer เวิร์กโฟลว์จะใช้ซีเคร็ต OPENCLAW_TRUSTED_PACKAGE_TOKEN แบบคงที่ โดยยังคงปฏิเสธข้อมูลรับรองที่ฝังใน URL
• source=artifact ดาวน์โหลด .tgz หนึ่งรายการจาก artifact_run_id และ artifact_name; package_sha256 เป็นตัวเลือก แต่ควรระบุสำหรับอาร์ติแฟกต์ที่แชร์ภายนอก

แยก workflow_ref และ package_ref ออกจากกัน workflow_ref คือโค้ดเวิร์กโฟลว์/ชุดทดสอบที่เชื่อถือได้ซึ่งเรียกใช้การทดสอบ package_ref คือคอมมิตซอร์สที่จะถูกแพ็กเมื่อ source=ref วิธีนี้ช่วยให้ชุดทดสอบปัจจุบันตรวจสอบคอมมิตซอร์สเก่าที่เชื่อถือได้โดยไม่ต้องเรียกใช้ตรรกะเวิร์กโฟลว์เก่า

โปรไฟล์ชุดทดสอบ

• smoke — npm-onboard-channel-agent, gateway-network, config-reload
• package — npm-onboard-channel-agent, 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
• product — ชุด package ที่มีความครอบคลุม plugins แบบใช้งานจริงแทน plugins-offline พร้อมด้วย mcp-channels, cron-mcp-cleanup, openai-web-search-minimal, openwebui
• full — ส่วนงานเส้นทางรีลีส Docker แบบเต็มพร้อม OpenWebUI
• custom — docker_lanes ที่ตรงกันทุกประการ; จำเป็นเมื่อ suite_profile=custom

โปรไฟล์ package ใช้ความครอบคลุม Plugin แบบออฟไลน์ เพื่อไม่ให้การตรวจสอบแพ็กเกจที่เผยแพร่แล้วขึ้นอยู่กับความพร้อมใช้งานของ ClawHub แบบใช้งานจริง เลน Telegram ที่เป็นตัวเลือกจะใช้อาร์ติแฟกต์ package-under-test ซ้ำใน NPM Telegram Beta E2E โดยยังคงเส้นทางข้อกำหนด npm ที่เผยแพร่แล้วไว้สำหรับการสั่งงานแบบสแตนด์อโลน

สำหรับนโยบายเฉพาะด้านการทดสอบการอัปเดตและ Plugin รวมถึงคำสั่งภายในเครื่อง เลน Docker, อินพุตการยอมรับแพ็กเกจ, ค่าเริ่มต้นของรีลีส และการคัดแยกความล้มเหลว โปรดดู การทดสอบการอัปเดตและ Plugin

การตรวจสอบรีลีสเรียกการยอมรับแพ็กเกจด้วย 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 วิธีนี้ทำให้การย้ายข้อมูลแพ็กเกจ การอัปเดต การติดตั้ง skill จาก ClawHub แบบใช้งานจริง การล้างดีเพนเดนซี Plugin ที่ล้าสมัย การซ่อมแซมการติดตั้ง Plugin ที่กำหนดค่าไว้ Plugin แบบออฟไลน์ การอัปเดต Plugin และหลักฐาน Telegram ใช้ tarball แพ็กเกจที่ระบุได้ชุดเดียวกัน ตั้งค่า release_package_spec ในการตรวจสอบรีลีสแบบเต็มหรือการตรวจสอบรีลีส OpenClaw หลังเผยแพร่ beta เพื่อเรียกใช้เมทริกซ์เดียวกันกับแพ็กเกจ npm ที่ส่งมอบแล้วโดยไม่สร้างใหม่ ตั้งค่า package_acceptance_package_spec เฉพาะเมื่อการยอมรับแพ็กเกจต้องใช้แพ็กเกจที่แตกต่างจากส่วนอื่นของการตรวจสอบรีลีส การตรวจสอบรีลีสข้ามระบบปฏิบัติการยังคงครอบคลุมการเริ่มต้นใช้งาน ตัวติดตั้ง และพฤติกรรมเฉพาะแพลตฟอร์ม ส่วนการตรวจสอบผลิตภัณฑ์ด้านแพ็กเกจ/การอัปเดตควรเริ่มจากการยอมรับแพ็กเกจ

เลน Docker published-upgrade-survivor ตรวจสอบฐานแพ็กเกจที่เผยแพร่แล้วหนึ่งรายการต่อการเรียกใช้ในเส้นทางรีลีสที่บล็อกอยู่ ในการยอมรับแพ็กเกจ tarball package-under-test ที่ระบุได้จะเป็นตัวเลือกเสมอ และ published_upgrade_survivor_baseline จะเลือกฐานที่เผยแพร่แล้วสำหรับใช้เป็นทางเลือกสำรอง โดยมีค่าเริ่มต้นเป็น openclaw@latest; คำสั่งเรียกใช้เลนที่ล้มเหลวซ้ำจะคงฐานนั้นไว้ การตรวจสอบรีลีสแบบเต็มที่มี run_release_soak=true หรือ release_profile=full จะตั้งค่า published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15' และ published_upgrade_survivor_scenarios=reported-issues เพื่อขยายการตรวจสอบให้ครอบคลุมรีลีส npm แบบ stable ล่าสุดสี่รายการ พร้อมรีลีสขอบเขตความเข้ากันได้ของ Plugin ที่ปักหมุดไว้และฟิกซ์เจอร์ที่จำลองรูปแบบปัญหาสำหรับการกำหนดค่า Feishu, ไฟล์ bootstrap/persona ที่เก็บรักษาไว้, การติดตั้ง Plugin OpenClaw ที่กำหนดค่าไว้, พาธล็อกที่ใช้ทิลเดอ และรากดีเพนเดนซี Plugin แบบเก่าที่ล้าสมัย การเลือกผู้รอดจากการอัปเกรดที่เผยแพร่แล้วแบบหลายฐานจะแบ่งชาร์ดตามฐานเป็นงานตัวรัน Docker แบบเจาะจงแยกกัน เวิร์กโฟลว์ Update Migration ที่แยกต่างหากใช้เลน Docker update-migration พร้อมฐาน all-since-2026.4.23 และสถานการณ์ plugin-deps-cleanup เมื่อคำถามคือการล้างข้อมูลการอัปเดตที่เผยแพร่แล้วอย่างครอบคลุม ไม่ใช่ขอบเขต CI รีลีสแบบเต็มตามปกติ การเรียกใช้แบบรวมภายในเครื่องสามารถส่งข้อกำหนดแพ็กเกจที่ตรงกันทุกประการด้วย OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS, คงเลนเดียวไว้ด้วย OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC เช่น [email protected] หรือตั้งค่า OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS สำหรับเมทริกซ์สถานการณ์ เลนที่เผยแพร่แล้วจะกำหนดค่าฐานด้วยชุดคำสั่ง openclaw config set ที่ฝังไว้ บันทึกขั้นตอนของชุดคำสั่งใน summary.json และตรวจสอบ /healthz, /readyz รวมถึงสถานะ RPC หลังเริ่ม Gateway เลนแพ็กเกจและตัวติดตั้งแบบใหม่ของ Windows ยังตรวจสอบด้วยว่าแพ็กเกจที่ติดตั้งสามารถนำเข้า browser-control override จากพาธ Windows แบบสัมบูรณ์ดิบได้ การทดสอบแบบ smoke ของ agent turn สำหรับ OpenAI ข้ามระบบปฏิบัติการจะใช้ OPENCLAW_CROSS_OS_OPENAI_MODEL เป็นค่าเริ่มต้นเมื่อมีการตั้งค่า มิฉะนั้นจะใช้ openai/gpt-5.6-luna เพื่อให้หลักฐานการติดตั้งและ Gateway ใช้ระดับทดสอบ GPT-5.6 ที่มีต้นทุนต่ำกว่า

ช่วงความเข้ากันได้กับระบบเก่า

การยอมรับแพ็กเกจมีช่วงความเข้ากันได้กับระบบเก่าที่มีขอบเขตจำกัดสำหรับแพ็กเกจที่เผยแพร่แล้ว แพ็กเกจจนถึง 2026.4.25 รวมถึง 2026.4.25-beta.* อาจใช้เส้นทางความเข้ากันได้:

• รายการ QA ส่วนตัวที่ทราบใน dist/postinstall-inventory.json อาจชี้ไปยังไฟล์ที่ถูกละเว้นจาก tarball;
• doctor-switch อาจข้ามกรณีย่อยด้านการคงอยู่ของ gateway install --wrapper เมื่อแพ็กเกจไม่เปิดเผยแฟล็กนั้น;
• update-channel-switch อาจตัด patchedDependencies ของ pnpm ที่หายไปออกจากฟิกซ์เจอร์ git จำลองที่ได้จาก tarball และอาจบันทึก update.channel ที่คงอยู่แต่หายไป;
• การทดสอบแบบ smoke ของ Plugin อาจอ่านตำแหน่งบันทึกการติดตั้งแบบเก่า หรือยอมรับการไม่คงอยู่ของบันทึกการติดตั้งจากมาร์เก็ตเพลส;
• plugin-update อาจอนุญาตการย้ายข้อมูลเมทาดาทาการกำหนดค่า โดยยังคงกำหนดให้บันทึกการติดตั้งและพฤติกรรมไม่ติดตั้งซ้ำต้องไม่เปลี่ยนแปลง

แพ็กเกจ 2026.4.26 ที่เผยแพร่แล้วอาจเตือนเกี่ยวกับไฟล์ประทับเมทาดาทาบิลด์ภายในเครื่องที่เคยส่งมอบแล้วได้เช่นกัน และแพ็กเกจจนถึง 2026.5.20 อาจเตือนแทนการล้มเหลวเมื่อ npm-shrinkwrap.json หายไป แพ็กเกจรุ่นหลังต้องเป็นไปตามสัญญาสมัยใหม่ โดยเงื่อนไขเดียวกันจะทำให้ล้มเหลวแทนการเตือนหรือข้าม

ตัวอย่าง

# ตรวจสอบแพ็กเกจ beta ปัจจุบันด้วยความครอบคลุมระดับผลิตภัณฑ์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 telegram_mode=mock-openai # ตรวจสอบแพ็กเกจ extended-stable ที่เผยแพร่แล้วด้วยความครอบคลุมระดับแพ็กเกจgh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@extended-stable \  -f suite_profile=package \  -f telegram_mode=mock-openai # แพ็กและตรวจสอบบรานช์รีลีสด้วยชุดทดสอบปัจจุบันgh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=ref \  -f package_ref=release/YYYY.M.PATCH \  -f suite_profile=package \  -f telegram_mode=mock-openai # ตรวจสอบ URL ของ tarball ต้องระบุ SHA-256 สำหรับ source=urlgh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=url \  -f package_url=https://example.com/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # ตรวจสอบ tarball จากนโยบายมิเรอร์ส่วนตัวที่เชื่อถือได้ซึ่งระบุชื่อไว้gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=trusted-url \  -f trusted_source_id=enterprise-artifactory \  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # ใช้ tarball ที่อัปโหลดโดยการเรียกใช้ Actions อื่นซ้ำgh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=artifact \  -f artifact_run_id=<run-id> \  -f artifact_name=package-under-test \  -f suite_profile=custom \  -f docker_lanes='install-e2e plugin-update'

เมื่อดีบักการเรียกใช้การยอมรับแพ็กเกจที่ล้มเหลว ให้เริ่มที่สรุป resolve_package เพื่อยืนยันแหล่งที่มาของแพ็กเกจ เวอร์ชัน และ SHA-256 จากนั้นตรวจสอบการเรียกใช้ลูก docker_acceptance และอาร์ติแฟกต์ Docker ได้แก่ .artifacts/docker-tests/**/summary.json, failures.json, ล็อกของเลน, ระยะเวลาของแต่ละเฟส และคำสั่งเรียกใช้ซ้ำ ควรเรียกใช้โปรไฟล์แพ็กเกจที่ล้มเหลวหรือเลน Docker ที่ระบุแน่นอนซ้ำ แทนการเรียกใช้การตรวจสอบรีลีสแบบเต็มซ้ำ

การทดสอบเบื้องต้นของการติดตั้ง

เวิร์กโฟลว์ Install Smoke จะไม่ทำงานบน pull request หรือการพุช main อีกต่อไป Wrapper สำหรับการทำงานรายคืน/ด้วยตนเองและการตรวจสอบความถูกต้องของรีลีสต่างเรียกใช้แกนหลัก install-smoke-reusable.yml แบบอ่านอย่างเดียว และทุกการทำงานจะดำเนินตามเส้นทางการทดสอบเบื้องต้นของการติดตั้งแบบเต็มบน Runner ที่โฮสต์โดย GitHub:

• อิมเมจทดสอบเบื้องต้นจาก Dockerfile รากจะถูกสร้างหนึ่งครั้งต่อ SHA เป้าหมาย ผูกกับรุ่นแก้ไขของเวิร์กโฟลว์และความพยายามของผู้ผลิตในอาร์ติแฟกต์แบบเปลี่ยนแปลงไม่ได้ จากนั้น CLI smoke, การทดสอบ CLI smoke ที่เอเจนต์ลบพื้นที่ทำงานร่วมกัน, E2E ของเครือข่าย Gateway ในคอนเทนเนอร์ และการทดสอบ build-arg ของ Plugin matrix ที่รวมมาในชุดจะโหลดอิมเมจดังกล่าว การทดสอบ Plugin จะตรวจสอบการทำมิเรอร์การติดตั้งการขึ้นต่อกันของรันไทม์ และตรวจสอบว่า Plugin โหลดได้โดยไม่มีการวินิจฉัยการหลุดออกจากจุดเข้า
• การติดตั้งแพ็กเกจ QR และการทดสอบ Docker เบื้องต้นของตัวติดตั้ง/การอัปเดต (รวมถึงเลนตัวติดตั้ง Rocky Linux และเลนอัปเดตเทียบกับค่าเริ่มต้น npm update_baseline_version ที่กำหนดค่าได้) จะทำงานเป็นงานแยกกัน เพื่อให้งานตัวติดตั้งไม่ต้องรอหลังการทดสอบอิมเมจราก

การทดสอบผู้ให้บริการอิมเมจสำหรับการติดตั้ง Bun แบบโกลบอลที่ทำงานช้าจะถูกควบคุมแยกต่างหากด้วย run_bun_global_install_smoke โดยทำงานตามกำหนดการรายคืน เปิดใช้โดยค่าเริ่มต้นสำหรับการเรียกเวิร์กโฟลว์จากการตรวจสอบรีลีส และการสั่งทำงาน Install Smoke ด้วยตนเองสามารถเลือกเข้าร่วมได้ CI ของ PR ปกติยังคงเรียกใช้เลนตรวจสอบการถดถอยของตัวเรียกใช้ Bun แบบรวดเร็วสำหรับการเปลี่ยนแปลงที่เกี่ยวข้องกับ Node การทดสอบ Docker สำหรับ QR และตัวติดตั้งยังคงใช้ Dockerfile ที่เน้นการติดตั้งของตนเอง

E2E ของ Docker ภายในเครื่อง

pnpm test:docker:all จะสร้างอิมเมจการทดสอบสดที่ใช้ร่วมกันล่วงหน้าหนึ่งอิมเมจ แพ็ก OpenClaw เป็น npm tarball หนึ่งครั้ง และสร้างอิมเมจ scripts/e2e/Dockerfile ที่ใช้ร่วมกันสองอิมเมจ:

• Runner Node/Git เปล่าสำหรับเลนตัวติดตั้ง/การอัปเดต/การขึ้นต่อกันของ Plugin;
• อิมเมจใช้งานจริงที่ติดตั้ง tarball เดียวกันลงใน /app สำหรับเลนการทำงานทั่วไป

ข้อกำหนดเลน Docker อยู่ใน scripts/lib/docker-e2e-scenarios.mjs ตรรกะของตัววางแผนอยู่ใน scripts/lib/docker-e2e-plan.mjs และ Runner จะดำเนินการเฉพาะแผนที่เลือก ตัวจัดกำหนดการเลือกอิมเมจต่อเลนด้วย OPENCLAW_DOCKER_E2E_BARE_IMAGE และ OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE จากนั้นเรียกใช้เลนด้วย OPENCLAW_SKIP_DOCKER_BUILD=1

ค่าที่ปรับแต่งได้

เลนที่หนักกว่าขีดจำกัดที่มีผลยังคงเริ่มจากพูลว่างได้ จากนั้นจะทำงานเพียงลำพังจนกว่าจะคืนความจุ ตัวรวมภายในเครื่องจะตรวจสอบ Docker ล่วงหน้า ลบคอนเทนเนอร์ OpenClaw E2E ที่ตกค้าง แสดงสถานะเลนที่กำลังทำงาน บันทึกเวลาของเลนเพื่อจัดลำดับจากนานที่สุดไปสั้นที่สุด และโดยค่าเริ่มต้นจะหยุดจัดกำหนดการเลนแบบพูลใหม่หลังจากเกิดความล้มเหลวครั้งแรก

เวิร์กโฟลว์สด/E2E ที่นำกลับมาใช้ใหม่ได้

เวิร์กโฟลว์สด/E2E ที่นำกลับมาใช้ใหม่ได้จะสอบถาม scripts/test-docker-all.mjs --plan-json ว่าต้องใช้แพ็กเกจ ชนิดอิมเมจ อิมเมจสด เลน และความครอบคลุมของข้อมูลประจำตัวใด จากนั้น scripts/docker-e2e.mjs จะแปลงแผนดังกล่าวเป็นเอาต์พุตและข้อมูลสรุปของ GitHub โดยจะเลือกแพ็ก OpenClaw ผ่าน scripts/package-openclaw-for-docker.mjs, ดาวน์โหลดอาร์ติแฟกต์แพ็กเกจของการทำงานปัจจุบัน หรือดาวน์โหลดอาร์ติแฟกต์แพ็กเกจจาก package_artifact_run_id แล้วตรวจสอบรายการภายใน tarball เส้นทางเริ่มต้น no-push-artifact จะสร้างอิมเมจเปล่า/ใช้งานจริงที่ติดแท็กด้วยไดเจสต์ของแพ็กเกจผ่านแคชเลเยอร์ Docker ของ Blacksmith แพ็กไบต์ของอิมเมจที่ตรงกันทุกประการลงในอาร์ติแฟกต์เวิร์กโฟลว์แบบเปลี่ยนแปลงไม่ได้ และให้ผู้ใช้แต่ละรายตรวจสอบและโหลดอาร์ติแฟกต์นั้น ส่วน existing-only ต้องระบุการอ้างอิง GHCR docker_e2e_bare_image/docker_e2e_functional_image อย่างชัดเจนแทน และจะไม่สร้างหรือพุช การดึงจากรีจิสทรีเหล่านั้นใช้ระยะหมดเวลาต่อความพยายามแบบจำกัดที่ 180 วินาที เพื่อให้สตรีมที่ค้างลองใหม่อย่างรวดเร็ว แทนที่จะใช้เวลาส่วนใหญ่ของเส้นทางวิกฤตใน CI หลังการตรวจสอบตามกำหนดการสำเร็จ openclaw-scheduled-live-checks.yml จะส่งแมนิเฟสต์อิมเมจที่ทดสอบแล้วแบบเปลี่ยนแปลงไม่ได้ไปยังผู้เผยแพร่ที่เขียนแพ็กเกจแยกต่างหาก ผู้เรียกรีลีสและพรีรีลีสแบบอ่านอย่างเดียวจะไม่ผ่านตัวเขียนนั้น

ส่วนย่อยของเส้นทางรีลีส

ความครอบคลุม Docker ของรีลีสจะทำงานเป็นงานส่วนย่อยขนาดเล็กด้วย OPENCLAW_SKIP_DOCKER_BUILD=1 เพื่อให้แต่ละส่วนย่อยตรวจสอบและโหลดเฉพาะชนิดอิมเมจที่มีอาร์ติแฟกต์รองรับตามที่ต้องใช้ (หรือดึงอิมเมจภายใต้การใช้ซ้ำ existing-only ที่ระบุอย่างชัดเจน) และดำเนินการหลายเลนผ่านตัวจัดกำหนดการแบบถ่วงน้ำหนักเดียวกัน:

• OPENCLAW_DOCKER_ALL_PROFILE=release-path
• OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui

ส่วนย่อย 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 โดย package-update-openai รวมเลนแพ็กเกจ Plugin Codex แบบสด ซึ่งติดตั้งแพ็กเกจ OpenClaw ตัวเลือก ติดตั้ง Plugin Codex จาก codex_plugin_spec หรือ tarball ของการอ้างอิงเดียวกันโดยมีการอนุมัติการติดตั้ง Codex CLI อย่างชัดเจน เรียกใช้การตรวจสอบล่วงหน้าของ Codex CLI และรอบการทำงานของเอเจนต์ในเซสชันเดียวกัน จากนั้นเรียกใช้รอบที่ไม่มีการลองใหม่และใช้การคิดระดับปานกลาง ซึ่งส่งความคืบหน้า อ่านอินพุตพื้นที่ทำงานแบบสุ่ม เขียนอาร์ติแฟกต์ที่ตรงกันทุกประการ และส่งการแจ้งเสร็จสมบูรณ์ plugins-runtime-core, plugins-runtime และ plugins-integrations ยังคงเป็นนามแฝงรวมของ Plugin/รันไทม์ นามแฝงเลน install-e2e ยังคงเป็นนามแฝงรวมสำหรับการเรียกซ้ำด้วยตนเองของเลนตัวติดตั้งผู้ให้บริการทั้งสอง

OpenWebUI ทำงานเป็นส่วนย่อย openwebui แบบสแตนด์อโลนบน Runner Blacksmith ที่มีดิสก์ขนาดใหญ่โดยเฉพาะ เมื่อใดก็ตามที่ความครอบคลุมเส้นทางรีลีสแบบเสถียรหรือแบบเต็มร้องขอ แม้ในกรณีที่เวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้กำหนดเส้นทางงานที่รองรับไปยัง Runner ที่โฮสต์โดย GitHub การแยกการดึงอิมเมจภายนอกออกมาต่างหากช่วยป้องกันไม่ให้อิมเมจขนาดใหญ่แข่งขันกับแพ็กเกจและอิมเมจ Plugin ที่ใช้ร่วมกันใน plugins-runtime-services; ส่วนย่อยรวม Plugin/รันไทม์แบบเดิมยังคงรวม OpenWebUI สำหรับการเรียกซ้ำด้วยตนเองที่เข้ากันได้ เลนอัปเดตช่องทางที่รวมมาในชุดจะลองใหม่หนึ่งครั้งเมื่อเกิดความล้มเหลวชั่วคราวของเครือข่าย npm

แต่ละส่วนย่อยจะอัปโหลด .artifacts/docker-tests/ พร้อมบันทึกของเลน เวลา summary.json, failures.json, เวลาของแต่ละเฟส, JSON แผนตัวจัดกำหนดการ, ตารางเลนที่ทำงานช้า และคำสั่งเรียกซ้ำต่อเลน อินพุตเวิร์กโฟลว์ docker_lanes จะเรียกใช้เลนที่เลือกกับอิมเมจที่เตรียมไว้สำหรับการทำงานนั้นแทนงานส่วนย่อย ซึ่งจำกัดการดีบักเลนที่ล้มเหลวไว้ที่งาน Docker เป้าหมายเพียงงานเดียว หากเลนที่เลือกเป็นเลน Docker แบบสด งานเป้าหมายจะสร้างอิมเมจการทดสอบสดภายในเครื่องสำหรับการเรียกซ้ำนั้น ตัวช่วยเรียกซ้ำจะตรวจสอบ SHA เป้าหมายที่เลือกอย่างตรงกันทุกประการของอาร์ติแฟกต์ความล้มเหลว และการสั่งทำงานด้วยตนเองจะแพ็กการอ้างอิงนั้นใหม่ เนื่องจากทูเพิลแพ็กเกจภายในของเวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้ไม่ใช่ส่วนหนึ่งของสคีมา workflow_dispatch คำสั่งที่สร้างขึ้นจะรวมอินพุตอิมเมจที่เตรียมไว้และ shared_image_policy=existing-only เฉพาะเมื่ออินพุตเหล่านั้นมี GHCR รองรับ; แท็กอาร์ติแฟกต์เฉพาะ Runner จะถูกละไว้ เพื่อให้ Runner ใหม่สร้างแท็กดังกล่าวขึ้นใหม่ การแทนที่เป้าหมายอย่างชัดเจนจะทิ้งการอ้างอิงอิมเมจ GHCR ที่กู้คืนมา เว้นแต่อาร์ติแฟกต์จะพิสูจน์ว่าตรงกับค่าที่แทนที่ การอ้างอิงข้อกำหนดเวิร์กโฟลว์ที่สร้างจากอาร์ติแฟกต์จะถูกละไว้เช่นกัน เนื่องจากสาขาชั่วคราวของรีลีสแบบเต็มจะถูกลบ การสั่งทำงานจะใช้สาขาเริ่มต้นของที่เก็บ เว้นแต่ผู้ปฏิบัติงานจะระบุค่าแทนที่อย่างชัดเจน

pnpm test:docker:rerun <run-id>      # ดาวน์โหลดอาร์ติแฟกต์ Docker และแสดงคำสั่งเรียกซ้ำแบบกำหนดเป้าหมายทั้งแบบรวม/ต่อเลนpnpm test:docker:timings <summary>   # ข้อมูลสรุปเลนที่ทำงานช้าและเส้นทางวิกฤตของแต่ละเฟส

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

พรีรีลีสของ Plugin

Plugin Prerelease เป็นความครอบคลุมผลิตภัณฑ์/แพ็กเกจที่มีค่าใช้จ่ายสูงกว่า จึงเป็นเวิร์กโฟลว์แยกที่สั่งทำงานโดย Full Release Validation หรือผู้ปฏิบัติงานที่ระบุอย่างชัดเจน Pull request ปกติ การพุช main และการสั่งทำงาน CI ด้วยตนเองแบบสแตนด์อโลนจะไม่เปิดใช้ชุดดังกล่าว เวิร์กโฟลว์นี้กระจายการทดสอบ Plugin ที่รวมมาในชุดให้สมดุลระหว่าง Worker ส่วนขยายแปดตัว งานชาร์ดส่วนขยายเหล่านั้นจะเรียกใช้กลุ่มการกำหนดค่า Plugin ได้พร้อมกันสูงสุดสองกลุ่ม โดยมี Worker Vitest หนึ่งตัวต่อกลุ่มและฮีป Node ที่ใหญ่ขึ้น เพื่อไม่ให้ชุด Plugin ที่มีการนำเข้าจำนวนมากสร้างงาน CI เพิ่มเติม เส้นทาง Docker สำหรับพรีรีลีสเฉพาะรีลีส (เปิดใช้โดยอินพุต full_release_validation) จะรวมเลน Docker เป้าหมายเป็นกลุ่มละสี่ เพื่อหลีกเลี่ยงการจอง Runner หลายสิบตัวสำหรับงานที่ใช้เวลาหนึ่งถึงสามนาที เวิร์กโฟลว์ยังอัปโหลดอาร์ติแฟกต์ plugin-inspector-advisory เพื่อให้ข้อมูลจาก @openclaw/plugin-inspector; ผลการตรวจสอบเป็นอินพุตสำหรับการคัดแยก และไม่เปลี่ยนเกต Plugin Prerelease ที่บล็อกอยู่

QA Lab

QA Lab มีเลน CI เฉพาะนอกเวิร์กโฟลว์หลักที่กำหนดขอบเขตอย่างชาญฉลาด ความเท่าเทียมของ Agentic ซ้อนอยู่ภายใต้ Harness QA และรีลีสแบบกว้าง ไม่ใช่เวิร์กโฟลว์ PR แบบสแตนด์อโลน ใช้ Full Release Validation กับ rerun_group=qa-parity เมื่อต้องการให้ความเท่าเทียมทำงานร่วมกับการตรวจสอบแบบกว้าง

• เวิร์กโฟลว์ QA-Lab - All Lanes ทำงานทุกคืนบน main และเมื่อสั่งทำงานด้วยตนเอง โดยกระจายงานความเท่าเทียมแบบจำลองและงาน Matrix, Telegram, Discord, WhatsApp และ Slack แบบสด งานสดใช้สภาพแวดล้อม qa-live-shared; Telegram, Discord, WhatsApp และ Slack ใช้สัญญาเช่า Convex ส่วน Matrix จัดเตรียมข้อมูลประจำตัวภายในเครื่องแบบใช้แล้วทิ้ง

การตรวจสอบรีลีสจะเรียกใช้เลนการขนส่ง Matrix และ Telegram แบบสดด้วยผู้ให้บริการจำลองที่กำหนดผลลัพธ์ได้และโมเดลที่ระบุคุณสมบัติเป็นแบบจำลอง (mock-openai/gpt-5.6-luna และ mock-openai/gpt-5.6-luna-alt) เพื่อแยกสัญญาช่องทางออกจากเวลาแฝงของโมเดลสดและการเริ่มต้น Plugin ผู้ให้บริการตามปกติ Gateway สำหรับการขนส่งสดจะปิดใช้การค้นหาหน่วยความจำ เนื่องจากความเท่าเทียมของ QA ครอบคลุมพฤติกรรมหน่วยความจำแยกต่างหาก ส่วนการเชื่อมต่อผู้ให้บริการครอบคลุมโดยชุดโมเดลสด ผู้ให้บริการเนทีฟ และผู้ให้บริการ Docker ที่แยกต่างหาก

เกต Matrix ตามกำหนดการและของรีลีสใช้โฮสต์ชุด QA Lab ที่ใช้ร่วมกันและอะแดปเตอร์สดกับสถานการณ์รีลีส ค่าเริ่มต้นของ CLI และอินพุตเวิร์กโฟลว์ด้วยตนเองยังคงเป็น all; การสั่งทำงาน all ด้วยตนเองจะกระจายโปรไฟล์ transport, media, e2ee-smoke, e2ee-deep และ e2ee-cli เพื่อให้หลักฐาน 93 สถานการณ์อยู่ภายในระยะหมดเวลาต่องาน การสั่งทำงานด้วยตนเองแบบเจาะจงจะเลือก fast, release หรือ transport ในงานเดียว

OpenClaw Release Checks ยังเรียกใช้เลน QA Lab ที่สำคัญต่อรีลีสก่อนการอนุมัติรีลีส เกตความเท่าเทียมของ QA จะเรียกใช้แพ็กตัวเลือกและแพ็กค่าพื้นฐานเป็นงานเลนแบบขนาน จากนั้นดาวน์โหลดอาร์ติแฟกต์ทั้งสองไปยังงานรายงานขนาดเล็กเพื่อเปรียบเทียบความเท่าเทียมขั้นสุดท้าย

สำหรับ PR ปกติ ให้ใช้หลักฐาน CI/การตรวจสอบตามขอบเขต แทนการถือว่าความเท่าเทียมเป็นสถานะที่จำเป็น

CodeQL

เวิร์กโฟลว์ CodeQL ตั้งใจให้เป็นเครื่องสแกนความปลอดภัยรอบแรกที่มีขอบเขตแคบ ไม่ใช่การกวาดตรวจทั้งที่เก็บ การทำงานรายวัน ด้วยตนเอง การพุช main และการทำงานป้องกันสำหรับ pull request ที่ไม่ใช่ฉบับร่าง จะสแกนโค้ดเวิร์กโฟลว์ Actions รวมถึงพื้นผิว JavaScript/TypeScript ที่มีความเสี่ยงสูงสุด ด้วยคิวรีความปลอดภัยที่มีความเชื่อมั่นสูงซึ่งกรองเป็น security-severity ระดับสูง/วิกฤต

ตัวป้องกัน pull request ยังคงมีขอบเขตเบา โดยจะเริ่มทำงานเฉพาะเมื่อมีการเปลี่ยนแปลงภายใต้ .github/actions, .github/codeql, .github/workflows, packages, scripts, src หรือพาธรันไทม์ของ Plugin แบบรวมที่เป็นเจ้าของกระบวนการ และจะเรียกใช้เมทริกซ์ความปลอดภัยความเชื่อมั่นสูงชุดเดียวกับเวิร์กโฟลว์ตามกำหนดการ ส่วน CodeQL สำหรับ Android และ macOS จะไม่รวมอยู่ในค่าเริ่มต้นของ PR

หมวดหมู่ความปลอดภัย

ชาร์ดความปลอดภัยเฉพาะแพลตฟอร์ม

• CodeQL Android Critical Security — ชาร์ดความปลอดภัย Android ตามกำหนดการ สร้างแอป Android ด้วยตนเองสำหรับ CodeQL บนรันเนอร์ Blacksmith Linux ที่เล็กที่สุดซึ่งผ่านการตรวจสอบความสมเหตุสมผลของเวิร์กโฟลว์ อัปโหลดภายใต้ /codeql-critical-security/android
• CodeQL macOS Critical Security — ชาร์ดความปลอดภัย macOS แบบรายสัปดาห์/เรียกด้วยตนเอง สร้างแอป macOS ด้วยตนเองสำหรับ CodeQL บน Blacksmith macOS กรองผลลัพธ์การสร้างของการอ้างอิงออกจาก SARIF ที่อัปโหลด และอัปโหลดภายใต้ /codeql-critical-security/macos โดยแยกออกจากค่าเริ่มต้นรายวัน เนื่องจากการสร้างบน macOS ใช้เวลาส่วนใหญ่ของรันไทม์แม้ไม่มีปัญหา

หมวดหมู่คุณภาพระดับวิกฤต

CodeQL Critical Quality คือชาร์ดคู่กันที่ไม่ใช่ด้านความปลอดภัย โดยเรียกใช้เฉพาะคิวรีคุณภาพ JavaScript/TypeScript ที่ไม่ใช่ด้านความปลอดภัยและมีระดับความรุนแรงเป็นข้อผิดพลาด บนพื้นผิวมูลค่าสูงที่มีขอบเขตแคบโดยใช้รันเนอร์ Linux ที่โฮสต์โดย GitHub เพื่อไม่ให้การสแกนคุณภาพใช้งบประมาณการลงทะเบียนรันเนอร์ Blacksmith ตัวป้องกัน pull request ของชาร์ดนี้ตั้งใจให้มีขอบเขตเล็กกว่าโปรไฟล์ตามกำหนดการ โดย PR ที่ไม่ใช่ฉบับร่างจะเรียกใช้เฉพาะชาร์ดที่ตรงกับพื้นผิวซึ่งมีการแก้ไข จากชาร์ดที่กำหนดเส้นทาง PR ได้ทั้งหมด 13 ชาร์ด ได้แก่ agent-runtime-boundary, channel-runtime-boundary, config-boundary, core-auth-secrets, gateway-runtime-boundary, mcp-process-runtime-boundary, memory-runtime-boundary, network-runtime-boundary, plugin-boundary, plugin-sdk-package-contract, plugin-sdk-reply-runtime, provider-runtime-boundary และ session-diagnostics-boundary ส่วน ui-control-plane และ web-media-runtime-boundary จะไม่รวมอยู่ในการเรียกใช้ของ PR การเปลี่ยนแปลงการกำหนดค่า CodeQL และเวิร์กโฟลว์คุณภาพจะเรียกใช้ชุดชาร์ด PR ทั้งหมด (ชาร์ดรันไทม์เครือข่ายจะใช้ไฟล์การกำหนดค่า CodeQL ของตนเองและพาธซอร์สที่เป็นเจ้าของเครือข่ายเป็นตัวกำหนด)

การสั่งทำงานด้วยตนเองรองรับ:

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

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

คุณภาพยังคงแยกจากความปลอดภัย เพื่อให้สามารถกำหนดเวลา วัดผล ปิดใช้งาน หรือขยายผลการตรวจพบด้านคุณภาพได้โดยไม่บดบังสัญญาณด้านความปลอดภัย การขยาย CodeQL สำหรับ Swift, Python และ Plugin แบบรวมควรเพิ่มกลับเข้ามาเฉพาะในรูปแบบงานติดตามผลที่กำหนดขอบเขตหรือแบ่งชาร์ดแล้ว หลังจากโปรไฟล์ขอบเขตแคบมีรันไทม์และสัญญาณที่เสถียร

เวิร์กโฟลว์การบำรุงรักษา

เอเจนต์เอกสาร

เวิร์กโฟลว์ Docs Agent เป็นเลนการบำรุงรักษา Codex แบบขับเคลื่อนด้วยเหตุการณ์สำหรับทำให้เอกสารที่มีอยู่สอดคล้องกับการเปลี่ยนแปลงที่เพิ่งรวมเข้า ไม่มีการทำงานตามกำหนดเวลาเพียงอย่างเดียว โดยการเรียกใช้ CI จากการพุชที่สำเร็จและไม่ได้มาจากบอตบน main สามารถทริกเกอร์ได้ และการสั่งทำงานด้วยตนเองสามารถเรียกใช้ได้โดยตรง การเรียกใช้จาก workflow-run จะข้ามเมื่อ main เดินหน้าไปแล้ว หรือเมื่อมีการสร้างการเรียกใช้ Docs Agent อื่นที่ไม่ได้ถูกข้ามภายในชั่วโมงที่ผ่านมา เมื่อทำงาน ระบบจะตรวจสอบช่วงคอมมิตตั้งแต่ SHA ซอร์สของ Docs Agent ครั้งก่อนที่ไม่ได้ถูกข้ามจนถึง main ปัจจุบัน ดังนั้นการเรียกใช้หนึ่งครั้งต่อชั่วโมงจึงครอบคลุมการเปลี่ยนแปลงทั้งหมดบน main ที่สะสมตั้งแต่การตรวจเอกสารครั้งล่าสุดได้

เอเจนต์ประสิทธิภาพการทดสอบ

เวิร์กโฟลว์ Test Performance Agent เป็นเลนการบำรุงรักษา Codex แบบขับเคลื่อนด้วยเหตุการณ์สำหรับการทดสอบที่ทำงานช้า ไม่มีการทำงานตามกำหนดเวลาเพียงอย่างเดียว โดยการเรียกใช้ CI จากการพุชที่สำเร็จและไม่ได้มาจากบอตบน main สามารถทริกเกอร์ได้ แต่จะข้ามหากการเรียกใช้จาก workflow-run อื่นทำงานไปแล้วหรือกำลังทำงานอยู่ในวัน UTC เดียวกัน การสั่งทำงานด้วยตนเองจะข้ามเกตกิจกรรมรายวันนี้ เลนนี้สร้างรายงานประสิทธิภาพ Vitest แบบจัดกลุ่มของชุดทดสอบทั้งหมด อนุญาตให้ Codex แก้ไขประสิทธิภาพการทดสอบได้เฉพาะขนาดเล็กโดยคงความครอบคลุมไว้แทนการรีแฟกเตอร์วงกว้าง จากนั้นเรียกใช้รายงานชุดทดสอบทั้งหมดอีกครั้งและปฏิเสธการเปลี่ยนแปลงที่ลดจำนวนการทดสอบเส้นฐานที่ผ่าน รายงานแบบจัดกลุ่มจะบันทึกเวลาจริงและ RSS สูงสุดต่อการกำหนดค่าบน Linux และ macOS เพื่อให้การเปรียบเทียบก่อน/หลังแสดงเดลตาหน่วยความจำของการทดสอบควบคู่กับเดลตาระยะเวลา หากเส้นฐานมีการทดสอบที่ล้มเหลว Codex สามารถแก้ไขได้เฉพาะความล้มเหลวที่ชัดเจน และรายงานชุดทดสอบทั้งหมดหลังเอเจนต์ทำงานต้องผ่านก่อนคอมมิตสิ่งใด เมื่อ main เดินหน้าก่อนการพุชของบอตจะรวมเข้า เลนนี้จะรีเบสแพตช์ที่ผ่านการตรวจสอบ เรียกใช้ pnpm check:changed อีกครั้ง และลองพุชใหม่ ส่วนแพตช์เก่าที่ขัดแย้งกันจะถูกข้าม เลนนี้ใช้ Ubuntu ที่โฮสต์โดย GitHub เพื่อให้แอ็กชัน Codex คงแนวทางความปลอดภัยแบบตัดสิทธิ์ sudo เช่นเดียวกับเอเจนต์เอกสาร

PR ซ้ำหลังการรวม

เวิร์กโฟลว์ Duplicate PRs After Merge เป็นเวิร์กโฟลว์สำหรับผู้ดูแลที่เรียกใช้ด้วยตนเองเพื่อทำความสะอาดรายการซ้ำหลังการรวม ค่าเริ่มต้นเป็น dry-run และจะปิดเฉพาะ PR ที่ระบุไว้อย่างชัดเจนเมื่อ apply=true ก่อนเปลี่ยนแปลง GitHub ระบบจะตรวจสอบว่า PR ที่รวมเข้าได้รับการรวมแล้ว และรายการซ้ำแต่ละรายการมี issue อ้างอิงร่วมกันหรือมีฮังก์ที่เปลี่ยนแปลงทับซ้อนกัน

gh workflow run duplicate-after-merge.yml \  -f landed_pr=70532 \  -f duplicate_prs='70530,70592' \  -f apply=true

เกตการตรวจสอบภายในเครื่องและการกำหนดเส้นทางตามการเปลี่ยนแปลง

ตรรกะเลนตามการเปลี่ยนแปลงภายในเครื่องอยู่ใน scripts/changed-lanes.mjs และเรียกใช้โดย scripts/check-changed.mjs เกตการตรวจสอบภายในเครื่องนี้เข้มงวดกับขอบเขตสถาปัตยกรรมมากกว่าขอบเขตแพลตฟอร์ม CI แบบกว้าง:

• การเปลี่ยนแปลงโค้ดโปรดักชันหลักจะเรียกใช้การตรวจสอบชนิดของโปรดักชันหลักและการทดสอบหลัก รวมถึง lint/ตัวป้องกันหลัก
• การเปลี่ยนแปลงเฉพาะการทดสอบหลักจะเรียกใช้เฉพาะการตรวจสอบชนิดของการทดสอบหลักและ lint หลัก
• การเปลี่ยนแปลงโค้ดโปรดักชันของส่วนขยายจะเรียกใช้การตรวจสอบชนิดของโปรดักชันส่วนขยายและการทดสอบส่วนขยาย รวมถึง lint ส่วนขยาย
• การเปลี่ยนแปลงเฉพาะการทดสอบส่วนขยายจะเรียกใช้การตรวจสอบชนิดของการทดสอบส่วนขยายและ lint ส่วนขยาย
• การเปลี่ยนแปลง Plugin SDK สาธารณะหรือสัญญา Plugin จะขยายไปยังการตรวจสอบชนิดของส่วนขยาย เนื่องจากส่วนขยายพึ่งพาสัญญาหลักเหล่านั้น (การกวาดทดสอบส่วนขยายด้วย Vitest ยังคงเป็นงานทดสอบที่ต้องระบุชัดเจน)
• การเพิ่มหมายเลขเวอร์ชันเฉพาะเมทาดาทาการเผยแพร่จะเรียกใช้การตรวจสอบเวอร์ชัน/การกำหนดค่า/การอ้างอิงระดับรากแบบเจาะจง
• การเปลี่ยนแปลงระดับราก/การกำหนดค่าที่ไม่รู้จักจะล้มเหลวอย่างปลอดภัยไปยังเลนการตรวจสอบทั้งหมด

การกำหนดเส้นทางการทดสอบตามการเปลี่ยนแปลงภายในเครื่องอยู่ใน scripts/test-projects.test-support.mjs และตั้งใจให้มีต้นทุนต่ำกว่า check:changed โดยการแก้ไขการทดสอบโดยตรงจะเรียกใช้ตัวเอง การแก้ไขซอร์สจะเลือกการแมปที่ชัดเจนก่อน แล้วจึงเลือกการทดสอบข้างเคียงและรายการที่ขึ้นต่อกันตามกราฟการนำเข้า การกำหนดค่าการส่งในห้องกลุ่มที่ใช้ร่วมกันเป็นหนึ่งในการแมปที่ชัดเจน โดยการเปลี่ยนแปลงการกำหนดค่าการตอบกลับที่มองเห็นได้ในกลุ่ม โหมดการส่งการตอบกลับของซอร์ส หรือพรอมต์ระบบของเครื่องมือข้อความ จะกำหนดเส้นทางผ่านการทดสอบการตอบกลับหลัก รวมถึงรีเกรสชันการส่งของ Discord และ Slack เพื่อให้การเปลี่ยนแปลงค่าเริ่มต้นที่ใช้ร่วมกันล้มเหลวก่อนการพุช PR ครั้งแรก ใช้ OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed เฉพาะเมื่อการเปลี่ยนแปลงครอบคลุมฮาร์เนสกว้างพอจนชุดการแมปต้นทุนต่ำไม่ใช่ตัวแทนที่น่าเชื่อถือ

การตรวจสอบด้วย Testbox

Crabbox คือ wrapper สำหรับกล่องระยะไกลที่รีโพเป็นเจ้าของ ซึ่งใช้สำหรับการพิสูจน์บน Linux โดยผู้ดูแล เซสชันของเอเจนต์จะรันการทดสอบแบบเจาะจงหนึ่งหรือไม่กี่รายการและการตรวจสอบแบบสแตติกราคาถูกภายในเครื่อง เฉพาะกับซอร์สที่เชื่อถือได้และเมื่อการติดตั้ง dependency ที่มีอยู่พร้อมใช้งานเท่านั้น โดยใช้ Crabbox สำหรับชุดการทดสอบขนาดใหญ่ขึ้นและ งานที่ใช้ทรัพยากรประมวลผลสูง รวมถึงการ build, typecheck, การกระจายงาน lint, Docker, เลนแพ็กเกจ, E2E, การพิสูจน์แบบสด และความสอดคล้องกับ CI การพิสูจน์งานหนักของผู้ดูแลที่เชื่อถือได้ ใช้ blacksmith-testbox เป็นค่าเริ่มต้น และขณะนี้ .crabbox.yaml ก็ใช้ค่านี้เป็นค่าเริ่มต้นเช่นกัน เวิร์กโฟลว์ที่กำหนดค่าไว้ จะเติมข้อมูลรับรองของผู้ให้บริการและเอเจนต์ ดังนั้นโค้ดจากผู้ร่วมพัฒนาที่ไม่น่าเชื่อถือหรือ โค้ดจาก fork ต้องใช้ CI ของ fork ที่ไม่มีข้อมูลลับ หรือ AWS Crabbox โดยตรงที่ผ่านการทำให้ปลอดภัยแทน การรันบน AWS ที่ผ่านการทำให้ปลอดภัยจะตั้งค่า CRABBOX_ENV_ALLOW=CI, ส่ง --no-hydrate และใช้ HOME ระยะไกลชั่วคราวชุดใหม่ ซึ่งจะป้องกันไม่ให้ allowlist OPENCLAW_* ของรีโพและโปรไฟล์การยืนยันตัวตนที่มีอยู่เข้าถึงโค้ดที่ไม่น่าเชื่อถือ การรันเหล่านี้ใช้ lease ที่วอร์มใหม่และจัดสรรเฉพาะให้ซอร์สที่ไม่น่าเชื่อถือนั้นเท่านั้น ห้ามใช้ lease ที่เชื่อถือได้หรือเคยเติมข้อมูลรับรองแล้ว เรียกใช้ไบนารี Crabbox ที่เชื่อถือได้และติดตั้งไว้แล้วจาก checkout main ที่สะอาดและเชื่อถือได้ และดึงเฉพาะ PR ระยะไกลด้วย --fresh-pr เท่านั้น ห้ามรัน wrapper หรือการกำหนดค่าของ checkout ที่ไม่น่าเชื่อถือภายในเครื่อง ยกเลิกการตั้งค่า CRABBOX_AWS_INSTANCE_PROFILE และปฏิเสธการทำงานโดยค่าเริ่มต้น เว้นแต่ aws.instanceProfile ที่ resolve แล้วจะว่างเปล่า ก่อนการติดตั้ง/ทดสอบใด ๆ ให้ใช้เครื่องมือ ที่เชื่อถือได้ผ่านพาธแบบสัมบูรณ์เพื่อบังคับใช้โทเค็น IMDSv2, พิสูจน์ว่า endpoint ข้อมูลรับรอง IAM ส่งคืน 404 และเปรียบเทียบ git rev-parse HEAD ระยะไกลกับ SHA แบบเต็ม ของ head PR ที่ผ่านการรีวิวแล้ว ผูก lease เข้ากับ SHA นั้น และหยุด/วอร์มใหม่เมื่อ head เปลี่ยน อัปโหลด scripts/crabbox-untrusted-bootstrap.sh ที่เชื่อถือได้จาก main ที่สะอาด ควบคู่กับ --fresh-pr โดยจะติดตั้ง Node/pnpm เวอร์ชันที่ปักหมุดไว้ ตรวจสอบ SHA และ การปักหมุด package manager, แยก HOME ออกจากกัน, ติดตั้ง dependency แล้วจึงรัน การทดสอบที่ร้องขอ ยกเลิกการตั้งค่า override CRABBOX_TAILSCALE* ทั้งหมด บังคับใช้ --network public --tailscale=false, ล้างแฟล็ก exit-node/LAN และกำหนดให้ crabbox inspect รายงานว่าใช้เครือข่ายสาธารณะโดยไม่มีสถานะ Tailscale ก่อนอัปโหลดสคริปต์ใด ๆ ความจุ AWS/Hetzner ที่เป็นเจ้าของยังคงเป็นทางเลือกสำรองสำหรับเหตุขัดข้องของ Blacksmith, ปัญหาโควตา หรือการทดสอบที่ระบุให้ใช้ความจุที่เป็นเจ้าของอย่างชัดเจน

เอเจนต์จะไม่วอร์มล่วงหน้าสำหรับงานที่คาดว่าจะทำ ให้ขอ Testbox แบบ lazy เมื่อ คำสั่งงานหนักคำสั่งแรกพร้อม ใช้รหัส tbx_... ที่ได้รับกลับมาซ้ำสำหรับคำสั่งงานหนัก คำสั่งต่อ ๆ ไป ซิงค์ checkout ปัจจุบันในการรันทุกครั้ง และหยุดก่อนส่งมอบงาน

การรัน Blacksmith ผ่าน Crabbox จะวอร์ม, อ้างสิทธิ์, ซิงค์, รัน, รายงาน และล้าง Testbox แบบใช้ครั้งเดียว การตรวจสอบความสมเหตุสมผลของการซิงค์ในตัวจะหยุดทันทีเมื่อ git status --short บนกล่องที่ซิงค์แล้วแสดงการลบไฟล์ที่ติดตามอย่างน้อย 200 รายการ ซึ่งช่วยตรวจจับไฟล์รากที่หายไป เช่น pnpm-lock.yaml สำหรับ PR ที่ตั้งใจ ลบไฟล์จำนวนมาก ให้ตั้งค่า CRABBOX_ALLOW_MASS_DELETIONS=1 สำหรับคำสั่งระยะไกล

Crabbox ยังยุติการเรียกใช้ Blacksmith CLI ภายในเครื่องที่ค้างอยู่ใน ขั้นตอนซิงค์นานกว่าห้านาทีโดยไม่มีเอาต์พุตหลังการซิงค์ ตั้งค่า CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0 เพื่อปิดตัวป้องกันนี้ หรือใช้ค่ามิลลิวินาทีที่มากขึ้น สำหรับ diff ภายในเครื่องที่มีขนาดใหญ่ผิดปกติ

ก่อนการรันครั้งแรก ให้ตรวจสอบ wrapper จากรากของรีโพ:

pnpm crabbox:run -- --help | sed -n '1,120p'

wrapper ของรีโพจะปฏิเสธไบนารี Crabbox ที่ล้าสมัยและไม่ได้ประกาศรองรับผู้ให้บริการที่เลือก และการรันที่ใช้ Blacksmith ต้องใช้ Crabbox 0.22.0 หรือใหม่กว่า เพื่อให้ wrapper ได้รับพฤติกรรมปัจจุบันสำหรับการซิงค์ คิว และการล้าง Testbox ใน worktree ของ Codex หรือ checkout แบบ linked/sparse ให้หลีกเลี่ยงสคริปต์ pnpm crabbox:run ภายในเครื่อง เพราะ pnpm อาจปรับ dependency ให้สอดคล้องกันก่อน Crabbox เริ่มทำงาน ให้เรียกใช้ node wrapper โดยตรงแทน:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

เมื่อใช้ checkout ที่อยู่ข้างเคียง ให้ build ไบนารีภายในเครื่องที่ถูก ignore ใหม่ก่อนงานจับเวลาหรือพิสูจน์:

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

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

pnpm crabbox:run -- --provider blacksmith-testbox \  --blacksmith-org openclaw \  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \  --blacksmith-job check \  --blacksmith-ref main \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm check:changed"

รันการทดสอบแบบเจาะจงซ้ำบน Testbox เมื่อ dependency ภายในเครื่องไม่พร้อมใช้งาน หรือ เป้าหมายกระจายงานออกไป:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test <path-or-filter>"

ชุดการทดสอบทั้งหมด:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test"

อ่านสรุป JSON สุดท้าย ฟิลด์ที่มีประโยชน์คือ provider, leaseId, syncDelegated, exitCode, commandMs และ totalMs สำหรับการรัน Blacksmith Testbox ที่มอบหมายให้ทำ รหัสออกของ Crabbox wrapper และสรุป JSON คือ ผลลัพธ์ของคำสั่ง การรัน GitHub Actions ที่เชื่อมโยงอยู่จะเป็นเจ้าของการเติมข้อมูลและ keepalive โดยอาจ สิ้นสุดด้วย cancelled เมื่อ Testbox ถูกหยุดจากภายนอกหลังจากคำสั่ง SSH ส่งผลลัพธ์กลับมาแล้ว ให้ถือว่านั่นเป็นอาร์ติแฟกต์ของการล้าง/สถานะ เว้นแต่ exitCode ของ wrapper จะไม่เป็นศูนย์ หรือเอาต์พุตคำสั่งแสดงว่าการทดสอบล้มเหลว การรัน Crabbox แบบใช้ครั้งเดียวที่ใช้ Blacksmith ควรหยุด Testbox โดยอัตโนมัติ หากการรันถูกขัดจังหวะหรือสถานะการล้างไม่ชัดเจน ให้ตรวจสอบกล่องที่ยังทำงานอยู่และหยุดเฉพาะ กล่องที่สร้างขึ้น:

blacksmith testbox list --allblacksmith testbox status --id <tbx_id>blacksmith testbox stop --id <tbx_id>

ใช้การนำกลับมาใช้ซ้ำเฉพาะเมื่อตั้งใจต้องรันหลายคำสั่งบนกล่องที่เติมข้อมูลแล้วกล่องเดียวกัน:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"pnpm crabbox:stop -- <tbx_id>

นำ lease กลับมาใช้ซ้ำ ไม่ใช่ซอร์สที่ล้าสมัย ละ --no-sync ไว้ เพื่อให้การรันแต่ละครั้งอัปโหลด checkout ปัจจุบัน ใช้ตัวเลือกนี้เฉพาะเมื่อตั้งใจรัน tree ที่ไม่เปลี่ยนแปลงและซิงค์ไว้แล้วซ้ำ โค้ดจากผู้ร่วมพัฒนาที่ไม่น่าเชื่อถือหรือจาก fork ต้องใช้ CRABBOX_ENV_ALLOW=CI, --provider aws --no-hydrate และ HOME ระยะไกล ชั่วคราวชุดใหม่สำหรับทุกคำสั่ง ติดตั้ง dependency ภายในคำสั่งที่ผ่านการทำให้ปลอดภัยนั้น ก่อนทดสอบ นำกลับมาใช้ซ้ำได้เฉพาะ lease ที่วอร์มใหม่และจัดสรรให้ซอร์สที่ไม่น่าเชื่อถือ ชุดเดียวกันเท่านั้น ห้ามใช้ lease ที่เชื่อถือได้หรือเคยเติมข้อมูลรับรองแล้ว ห้าม รัน wrapper หรือการกำหนดค่าของ checkout ที่ไม่น่าเชื่อถือภายในเครื่อง ให้เรียกใช้ไบนารี Crabbox ที่เชื่อถือได้และติดตั้งไว้แล้วจาก main ที่สะอาดและเชื่อถือได้ และส่ง --fresh-pr ในทุก การรัน คง CRABBOX_AWS_INSTANCE_PROFILE ไว้โดยไม่ตั้งค่า ปฏิเสธ instance profile ที่ resolve แล้วและไม่ว่างเปล่า กำหนดให้มีหลักฐาน IMDS ระยะไกลที่เชื่อถือได้ว่าไม่มีบทบาท และตรวจสอบ SHA ของ head ที่ผ่านการรีวิวแล้วก่อนติดตั้ง/ทดสอบ ผูก lease เข้ากับ SHA นั้น และหยุดแล้ว วอร์มใหม่หลังจาก head เปลี่ยนทุกครั้ง หากไม่มี PR ระยะไกล ให้ใช้ CI ของ fork ที่ไม่มีข้อมูลลับ ห้ามเลือก hydrate-github หรือเวิร์กโฟลว์ Blacksmith ที่เติมข้อมูลรับรองแล้ว สำหรับซอร์สที่ไม่น่าเชื่อถือ

หาก Crabbox เป็นชั้นที่เสีย แต่ Blacksmith เองยังทำงานได้ ให้ใช้ Blacksmith โดยตรงเฉพาะสำหรับการวินิจฉัย เช่น list, status และการล้าง แก้ไข เส้นทาง Crabbox ก่อนถือว่าการรัน Blacksmith โดยตรงเป็นหลักฐานสำหรับผู้ดูแล

หาก blacksmith testbox list --all และ blacksmith testbox status ทำงานได้ แต่การวอร์มใหม่ ค้างอยู่ที่ queued โดยไม่มี IP หรือ URL ของการรัน Actions หลังผ่านไปสองสามนาที ให้ถือว่าเป็นแรงกดดันจากผู้ให้บริการ Blacksmith, คิว, การเรียกเก็บเงิน หรือขีดจำกัดขององค์กร หยุด รหัสที่อยู่ในคิวซึ่งสร้างขึ้น หลีกเลี่ยงการเริ่ม Testbox เพิ่ม และย้ายการพิสูจน์ไปยัง เส้นทางความจุ Crabbox ที่เป็นเจ้าของด้านล่าง ระหว่างที่มีผู้ตรวจสอบแดชบอร์ด Blacksmith, การเรียกเก็บเงิน และขีดจำกัดขององค์กร

ยกระดับไปใช้ความจุ Crabbox ที่เป็นเจ้าของเฉพาะเมื่อ Blacksmith ใช้งานไม่ได้ ถูกจำกัดโควตา ไม่มีสภาพแวดล้อมที่ต้องการ หรือมีเป้าหมายให้ใช้ความจุที่เป็นเจ้าของอย่างชัดเจน:

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90mpnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

เมื่อ AWS อยู่ภายใต้แรงกดดัน ให้หลีกเลี่ยง class=beast เว้นแต่งานต้องใช้ CPU ระดับ 48xlarge จริง ๆ คำขอ beast เริ่มต้นที่ 192 vCPU และเป็นวิธีที่ง่ายที่สุดในการชนโควตา EC2 Spot หรือ On-Demand Standard ระดับภูมิภาค .crabbox.yaml ที่รีโพเป็นเจ้าของใช้ค่าเริ่มต้นเป็น class: standard, ตลาด on-demand และ capacity.hints: true เพื่อให้ lease AWS ผ่านโบรกเกอร์แสดงภูมิภาค/ตลาดที่เลือก แรงกดดันด้านโควตา การ fallback ไปใช้ Spot และคำเตือนคลาสที่มีแรงกดดันสูง ใช้ fast สำหรับการตรวจสอบวงกว้างที่หนักขึ้น ใช้ large หลังจาก standard/fast ไม่เพียงพอเท่านั้น และใช้ beast เฉพาะสำหรับเลนที่ผูกกับ CPU เป็นกรณีพิเศษ เช่น ชุดการทดสอบทั้งหมดหรือเมทริกซ์ Docker ของ Plugin ทั้งหมด การตรวจสอบ release/blocker ที่ระบุอย่างชัดเจน หรือการทำโปรไฟล์ประสิทธิภาพแบบหลายคอร์ ห้ามใช้ beast สำหรับ pnpm check:changed, การทดสอบแบบเจาะจง, งานเฉพาะเอกสาร, lint/typecheck ทั่วไป, การทำซ้ำ E2E ขนาดเล็ก หรือการไตร่สวนเหตุขัดข้องของ Blacksmith ใช้ --market on-demand สำหรับการวินิจฉัยความจุ เพื่อไม่ให้ความผันผวนของตลาด Spot ปะปนอยู่ในสัญญาณ

.crabbox.yaml เป็นเจ้าของค่าเริ่มต้นของผู้ให้บริการ การซิงค์ และการเติมข้อมูลผ่าน GitHub Actions การซิงค์ของ Crabbox จะไม่ถ่ายโอน .git ดังนั้น checkout ของ Actions ที่เติมข้อมูลแล้วจะเก็บข้อมูลเมตา Git ระยะไกลของตนเอง แทนที่จะซิงค์รีโมตและ object store ภายในเครื่องของผู้ดูแล และการกำหนดค่าของรีโพยังไม่รวมอาร์ติแฟกต์รันไทม์/build ภายในเครื่องเพิ่มเติม (เช่น .artifacts และรายงานการทดสอบ) ซึ่งไม่ควรถูกถ่ายโอนโดยเด็ดขาด .github/workflows/crabbox-hydrate.yml เป็นเจ้าของ checkout, การตั้งค่า Node/pnpm, การดึง origin/main และการส่งต่อสภาพแวดล้อมที่ไม่มีข้อมูลลับสำหรับคำสั่ง crabbox run --id <cbx_id> บนคลาวด์ที่เป็นเจ้าของ

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

• ภาพรวมการติดตั้ง
• ช่องทางการพัฒนา