openclaw-ci-limits

OpenClaw CI 限制

此技能用於 CI 容量變更，而非一般測試失敗分類。目標是保持 OpenClaw 快速，同時區分執行器註冊、執行器可用性、Blacksmith 控制平面健康狀況以及下游佇列耗盡。

核心事實

• 完整主層級 CI 每小時執行一次；一般主推送執行 security-fast。綠色推送不代表完整測試套件通過。一般 PR 會延後 Windows、macOS Node/Swift、iOS 建置/模擬器、真實 Gateway UI、已發布驅動程式更新、Knip 以及大部分架構驗證。匯入循環和 Kysely 防護仍然是阻擋條件。使用 docs/ci/scope-and-routing/selection.md 和當前 manifest 來確認確切的觸發事件、擁有者和發行版回退選擇；在調整容量時不要還原延後的管道。Android 螢幕截圖仍僅限發行版。
• 不要預設稀缺資源。需證明壓力來源是執行器註冊、合格執行器可用性、Blacksmith 容量/控制平面、工作流程相依性、測試執行時間還是下游佇列寫入器。
• openclaw 的 GitHub 執行器註冊目前在 actions_runner_registration 中回報為每 5 分鐘 10,000 個 bucket。在每次調整前驗證即時 bucket，因為 GitHub 可能會變更它。openclaw 組織共用一個 bucket。
• 核心 REST 配額不會消耗此 bucket。請單獨檢查 actions_runner_registration；核心配額可能健康，但執行器註冊可能已受到節流。
• 將即時 bucket 的大約 60% 作為操作目標。在當前 10,000 個註冊 bucket 下，請將計劃的 Blacksmith 爆發負載保持低於每 5 分鐘 6,000 個註冊，並將剩餘部分留給其他儲存庫、重試和爆發重疊。
• 負責路由、通知、總結、選擇分片或執行簡短 CodeQL 品質掃描的工作應留在 GitHub 託管執行器上，除非有測量證據表明需要 Blacksmith。

執行器成本政策

• 使用能夠可靠完成所需工作負載的最小執行器。將短暫的控制工作留在託管環境，並將一般可信的開發驗證保留在本地。
• 將實體 8 vCPU 及更大的執行器視為例外，而非預設或一般重試選項。記錄指令和測量的尖峯記憶體、較小執行器的 OOM，或顯示較低總計費成本的對照比較。僅低 CPU 使用率並不能證明記憶體密集型工作可以降級。保留基於資源的工作者限制。
• 常規 OpenClaw Testbox 使用 4 類別，預設總工作時間為 60 分鐘（包括初始化）。保持 15 分鐘的空閒上限。歡迎為已知的簡短指令設定更短的截止時間；不要自動請求四小時，或僅為了獲得更多時間而升級。僅針對指定的記憶體密集型指令明確選擇 .github/workflows/ci-check-high-memory-testbox.yml；請參閱 docs/reference/test/remote-proof.md。該工作流程在共用的 32 插槽 Testbox 池內最多有四個並發租用。高記憶體設定檔使用 8 個 vCPU；兩個設定檔都保留其 11 月 3 日之前的實體 CPU 和 RAM。所有 Testbox 設定檔的空閒時間上限為 15 分鐘。
• 透過工作流程參考 main 的當前 OpenClaw 包裝器進行分配；來源膠囊保留正在測試的簽出內容。不要排程舊的工作流程參考來繞過支出限制。佇列年齡在簽出前檢查；已接受的租用保留其工作和空閒截止時間。
• 不要因為一個指令需要更多 RAM 就升級整個工作流程家族。將經過驗證的高記憶體 CI 行保持在其所屬規劃器和證據的範圍內；在變更其分配之前重新測量。32 類別標籤並不代表有 32 個可用的 CPU。比較觀察到的資源和總計費工作成本。

被拒絕的實驗

• UI blobless 稀疏簽出 (2026-10-16)： 排除原生行動/macOS 應用程式樹移除了 48.31 MiB 的邏輯追蹤內容，但不符合執行器成本改善的資格。在執行序 38866595993 中，Blacksmith UI E2E 簽出花費 56 秒，而託管瀏覽器簽出花費 58 秒；同一執行的完整 UI 簽出花費 22–38 秒。這些是小型、未配對的樣本，而不是測量的帳單差異。保留完整原始碼簽出。只有在完整簽出時間和計費成本更低時才重新考慮，包括篩選提取、延遲實體化和可信匯出；邏輯位元組減少本身並不能建立節省。
• 宣告 fixture 擁有者選擇 (2026-10-02)： test/scripts/tsdown-declaration-fixture.ts 從其執行時入口點閉包衍生真實的原始碼副本，因此編輯其中一個的產品 PR 不會選擇建立於其上的四個宣告套件。PR #162614 以這種方式破壞了 write-unified-entry-dts；每小時排程的 CI (執行序 36979748808) 在合併後約 35 分鐘捕獲到它，並且 0a188c4f038f0 在一小時內修復了 fixture。將擁有者宣告為 new URL(..., import.meta.url) 文字僅在低於積極選擇的 20 導入器樞紐截止點時才會到達套件：事件擁有者和其他七個是樞紐，因此重播的 #162614 diff 仍然沒有選擇任何套件。透過規範的 PR 規劃器選項，重播過去 30 天內所有觸及擁有者的 92 個主要提交，URL 文字新覆蓋了 12 個（+35 行，+1,689 類別 vCPU 分鐘）。完整覆蓋，例如對相同清單的政策監控，會新選擇 81 個套件的套件，並啟動 build-artifacts（在 16 類別上，跨 12 個 PR 執行，中位數 330 秒）用於 69 個套件，因為這些套件是 ci-build-manifest.mjs 中的建置擁有者：+242 行和 +11,628 類別 vCPU 分鐘，每個受影響的 PR 中位數增加 +161（+8%）。這在七週內買到一個逃脫的擁有者破壞，因此保留簡單路徑；每小時排程的 CI、工具擁有者 PR 和發行版驗證負責此驗證。只有在逃脫率實質上更高或選擇不會同時啟動 build-artifacts 時才重新考慮。
• 邊界非同步輸入準備 (2026-09-26)： 在三個宣告/邊界呼叫者處添加現有的 CompilerInputSnapshot.prepare() 呼叫，將完整冷驗證從 464.21 秒增加到 544.68 秒（在相同的 4-CPU/15.42 GiB Testbox 上）；熱驗證從 12.62 秒增加到 14.63 秒。所有 125 個外掛檢查和 canary 都通過，但 CPU 使用率也增加了。六個呼叫者新增已被移除。不要將其重複視為假設的加速；任何不同的使用都需要測量的端到端效益。
• Windows pnpm 儲存 (2026-09-20)： 來自執行序 35547255790的原始收據測量冷設定中位數為 45.295 秒，而恢復後為 52.738 秒（+16.4%），儘管重複使用了全部 1,453 個套件且零下載。763.8 MiB 的存檔需要 23.601–26.980 秒來恢復；生產者設定/儲存增加了 62.527 秒。所有七個原生工作都通過，但資格減少器因 24 KiB 的報告 RAM 差異而失敗。沒有放鬆任何斷言或重新執行工作。完全 RAM 匹配的子集仍然慢 11.3%；這是描述性證據，而非通過資格的替代方案。保持正常的 Windows 設定不進行快取。只有在淨完整設定節省（包括恢復、提取、凍結協調和生產者工作）時才重新考慮。
• 託管 Mac 精確相依性 (2026-09-01)： 執行序 33458856298 中的相同標頭發布者和消費者成功儲存和恢復了一個 1.66 GB 的相依性存檔，但設定花費了 142 秒，而使用普通儲存快取則為 86 秒。提取花費了 82 秒，而普通快取為 27 秒；安裝僅從 43 秒改善到 35 秒。將託管 Mac 工作保留在普通儲存快取上。只有在測量的總設定節省（包括傳輸、提取和凍結協調）時才重新考慮，而不僅僅是快取命中。
• Actions-artifact 簽出 (2026-08-16)： 不要建議用預先產生的工作空間或 .git 工件取代共用的 Blacksmith Git 提取。PR #124818 測量了 Blacksmith 簽出基線為 16 秒，而託管為 7 秒。最佳的工件變體花費 1 秒打包、3 秒上傳和 11 秒中位數恢復；包括序列前綴僅留下約 1 秒的中位數改善，並使 Blacksmith 的快速提取執行發生迴歸。官方的工件客戶端更差：執行序 31971531521 測量了中位數下載 22 秒加上 2 秒實體化。Blacksmith 的快速 Actions-cache 路徑並不意味著快速的 Actions-artifact 下載。只有在針對不同傳輸方式提供測量的端到端證明（包括其生產者成本及快速提取迴歸）時才重新考慮。

初步檢查

在變更 CI 之前，收集當前壓力：

gh api rate_limit --jq '{core:.resources.core,graphql:.resources.graphql,search:.resources.search,actions_runner_registration:.resources.actions_runner_registration}'
gh run list -R openclaw/openclaw --limit 20 --json databaseId,status,conclusion,workflowName,event,headBranch,createdAt,updatedAt,url
gh run list -R openclaw/clawsweeper --limit 20 --json databaseId,status,conclusion,workflowName,event,headBranch,createdAt,updatedAt,url
gh api repos/openclaw/clawsweeper/actions/runs/<run-id>/jobs --paginate --jq '.jobs[] | {id,name,status,conclusion,labels,created_at,started_at,completed_at,runner_name,runner_group_name}'
blacksmith testbox list --all
curl -fsS https://clawsweeper.openclaw.ai/api/status | jq '{generated_at,fleet,diagnostics:{errors:.diagnostics.errors}}'
curl -fsS https://clawsweeper.openclaw.ai/api/exact-review-queue | jq '{generated_at,review:.lanes.review,publication:.lanes.publication,state_writer,state_append}'
node scripts/ci-run-timings.mjs --latest-main
node scripts/ci-run-timings.mjs --recent 10

對於可疑的佇列執行，檢查其工作。執行層級的 queued 狀態無法揭示工作是等待相依性還是沒有可用的執行器。比較 created_at、started_at、labels 和 runner_name。在取消之前，重新檢查陳舊的佇列執行；僅取消被證明已過時的執行。

Testbox warmup 確認租用建立，而非執行器就緒。沒有 providerMetadata.runURL 的初始 queued 快照並不能確定容量短缺。一旦關聯，請使用該 URL 檢查確切的工作流程。一個被分配了 check 執行器正在執行設定的過程是初始化；已確認的接納或容量佇列遵循現有的停止自有分配政策。不要從最新的工作流程執行推斷關聯，也不要等待已確認的容量佇列。

scripts/ci-run-timings.mjs 的啟動延遲可能包括工作流程相依性等待加上執行器佇列時間。這僅是趨勢證據，而非單獨的執行器壓力證明。

閱讀：

• .github/workflows/ci.yml
• .github/workflows/codeql-critical-quality.yml
• docs/ci.md
• test/scripts/ci-workflow-guards.test.ts
• test/scripts/ci-workflow-planning.test.ts
• test/scripts/ci-workflow-evidence.test.ts
• 受影響的規劃器檔案，位於 scripts/lib/*ci*、scripts/lib/*test-plan* 或 scripts/ci-changed-scope.mjs 下

診斷瓶頸

在變更上限之前，先分類問題：

• 執行器註冊節流： 許多工作在分配執行器之前就已排入佇列，Blacksmith/GitHub 回報來自 generate-jitconfig 的 403/429 或垃圾郵件風格的 422 回應，而 API 核心配額仍然健康。僅在請求有效負載在其他方面都有效時，才將 422 視為此訊號。修正突發性和 Blacksmith 工作數量。
• Blacksmith 容量： Blacksmith 儀表板顯示實際的並發上限或不可用的容量。不要僅透過 GitHub 工作流程扇出來解決此問題。
• Blacksmith Testbox 控制平面： list、warmup、status 或 run 呼叫在返回租用之前超時。這與 Actions 執行器註冊和 Actions 工作容量不同。可信來源可能使用記錄在案的本地回退；不可信來源保持封鎖。
• 不可用的執行器標籤： 一個工作使用自訂 runs-on 標籤排入佇列，started_at 和 runner_name 保持空白，並且沒有可用的執行器。恢復可用的託管或已註冊標籤；扇出無法解決此問題。
• 工作流程相依性等待： 工作已排入佇列，但必要的前置任務尚未終止。修正或等待相依性；不要將整個延遲稱為執行器佇列壓力。
• OpenClaw 測試執行時間： 工作快速啟動，但一個管道佔據了大部分執行時間。使用 $openclaw-test-performance 而不是調整執行器。
• 真正的 CI 失敗： 一個工作在啟動後失敗。使用 $github:gh-fix-ci 或 $openclaw-testing，而非此技能。
• ClawSweeper 審查積壓： 審查待處理/就緒項目增加，而發布和狀態寫入器保持健康。調整 openclaw/clawsweeper 中的審查接納/工作者數量。
• ClawSweeper 發布積壓： 發布待處理/就緒項目和最舊年齡增加，淨耗盡為零或負數，或死信增加。首先檢查發布批次、狀態寫入器協調和 GitHub 變更延遲。
• 狀態實體化器/附加積壓： state_append.pending_rows、pending_bytes 或最舊年齡增加，而實體化器已排入佇列或不存在。首先恢復該唯一耗盡；更多的審查工作者會使情況更糟。

註冊預算計算

在編輯之前，估算變更的最壞情況註冊數量：

新的 Blacksmith 註冊數 ≈ 可以在一個 5 分鐘視窗內排入佇列的 Blacksmith 工作數量

對於矩陣工作，計算可以在 5 分鐘視窗內啟動的每一行。strategy.max-parallel 僅限制並發行；短行可以輪替並在視窗重置前註冊更多執行器。使用工作持續時間、重試和佇列輪換來證明任何較低估算的合理性。添加非矩陣的 Blacksmith 工作，例如 preflight、security-fast、build-artifacts 和平台管道。

對於重複 [...]

（內容因截斷而繼續）