CI 跑步班

运行器

Testbox 支出限额

集中、常规、通用、高内存、ARM、构建工件和 Windows Testbox 工作流程共享 32 个并发槽。在 Blacksmith 作业符合资格之前，GitHub-hosted 准入作业会验证租约 ID、运行程序和运行时。调度在其分配的时隙中等待，而不取消活动租约。使用GitHub的queue: max，每个槽最多保留100个待处理请求；较新的请求不会取代较早的服务员。当槽的队列已满时，GitHub 会取消其他请求。当每个作业进入槽队列时进行排序，而不是工作流调度时间。哈希冲突仍然可能导致其他槽位未使用；这是一个上限，而不是 32 台繁忙机器的承诺。

准入将在工作流程创建 60 分钟后过期。这种有界队列允许让等待的客户端在超过前十分钟截止时间的饱和状态下幸存下来，而无需接受任意旧的放弃请求。它是一个操作界限，而不是测量的队列百分位或客户端仍在等待的证据：委托的预热合约不会向这些工作流公开任何请求者心跳，并且 SSH 活动仅在运行程序分配后可用。当运行程序启动时，等待 60 分钟或更长时间的请求在结账或补充之前会失败；它仍然会产生运行者的启动成本。比绑定更年轻的废弃请求仍然可以进行水合，因此仍然需要调用者清理。这不会立即删除排队的作业，也不会在分配运行程序时重置时钟。一旦请求通过该检查，结帐和水合就不会重新检查队列年龄。它们仍然受到作业超时和空闲限制的限制。通过确切的 ID 停止废弃的租约，而不是让预热挂起。对于排队租约，还要验证其支持操作运行是否已终止； Blacksmith 的 completed 租赁状态本身并不能证明排队运行已取消。在取消放弃的运行之前，匹配准入作业日志中的确切 TESTBOX_ID；其标题或创作时间不够。如果该任务拥有的运行仍处于挂起状态，请使用 gh run cancel <run-id> --repo openclaw/openclaw 并确认其最终状态。如果租约到运行匹配不可用，请报告未解决的清理，而不是取消猜测的运行。当池已满时，不要在循环中重试。

如果准入作业无法读取其运行的 GitHub 操作，它将拒绝准入并报告 HTTP 状态、修复的错误分类以及经过验证的 GitHub 请求 ID 和速率 limit/retry 标头（如果可用）。在现有的 15 秒请求期限内，错误主体限制为 8 个 KiB；原始响应消息和正文永远不会被记录。裸露的 403 报告为 forbidden，不假定为权限或速率限制失败。使用请求 ID 调查原始 GitHub 响应；后来的成功请求并不能解释之前的拒绝。在稍后请求之前兑现 retry-after（秒）。当 x-ratelimit-remaining=0 时，等待 x-ratelimit-reset（UTC 纪元秒）。准入不会重试或更改令牌权限，并且失败的请求仍然需要调用者清理。

空闲请求的上限为 15 分钟。现有的 Testbox 监视器继续保护活动的 SSH 命令。任务完成后停止保留的租约；空闲限制不能替代调用者清理。

常规远程校样采用16级。显式高内存工作流程只能使用共享 32 个插槽中的 4 个；它不会再添加四个插槽。正常租约也可以占用这些插槽，因此哈希冲突可能会将高内存工作排队到其上限以下。完成后停止拥有的租约，而不是请求新的 ID 来避开繁忙的时段。

仅将 32 类用于具有测量内存需求的命名命令、经过验证的较小运行程序 OOM 或显示较低总计费成本的受控比较。分配前记录证据。显式的全套 Testbox PR 门保留了此例外；普通遥控指令和变闸采用16级。选型参见远传。失败的测试、队列延迟或一般超时都不能证明升级是合理的。

一般证明默认为 60 分钟（包括水合作用）。现有的 timeout_minutes 输入可以请求更短的期限或明确将已知的长证明延长至 240 分钟；较大的值在分配之前会失败。本机 Blacksmith 预热不会公开任意工作流程输入，并且 Crabbox --ttl 不会强制执行 Testbox 生命周期。 GitHub 作业超时是挂钟限制。

10 月 1 日的规模审核倾向于 16 级，而不是全面默认的 8 级。在过去 7 天中，5,521 次 32 级运行的中位寿命为 31 分钟，p95 为 108 分钟。内存采样器返回 4,436 次合格运行；采样的 median 和 p75 峰值分别为 6.2 和 12.8 GiB 与 8 类观察到的 7.66 GiB。在这些采样峰值处，总 RAM 减去可用 RAM 为 6.8 和 13.4 GiB，因此可回收缓存并不能解释较小类别的风险。单独的 6,199 个运行的 16 类人群还包括 25 个 OOM- 受影响的工作；这些人群的规模比较不受控制。

工作持续时间包括水合作用、命令和空闲保留。采样的 31- 分钟作业 在 Testbox 监视器中等待 30 分钟，空闲设置为 30 分钟。不要将租赁百分位数视为活动命令百分位数，也不要为新策略声明测量的超时率。默认 60 分钟是操作选择；在设置 15 分钟闲置上限后重新测量，然后再将 30 分钟或 8 级设为一般默认值。

这些控件涵盖使用此存储库中更新的工作流程的调度。 OpenClaw 包装器从 main 中为 Testbox run 和 warmup 选择工作流程，覆盖配置的引用并拒绝显式的历史引用。它的源胶囊仍然重建正在测试的结帐。旧包装器、直接历史引用调度、其他存储库、备用工作流程和 Windows 检查工作流程位于共享池之外。组织范围内的并发性、每个代币的准入、SKU 限制和硬性支出停止都需要提供商进行控制。

CI 跑步路线

当前的扩展包边界检查使用16级。冻结目标保留其历史 32 类运行器和编译器策略。

当设置输入为 24.x 时，托管 Node 24 设置遵循工作流程的现有 NODE_VERSION 引脚。这可以防止运行程序图像刷新默默地选择不同的补丁版本。显式兼容性版本保留其自己的选择，自托管设置保留其现有范围和工具链缓存策略。恢复的缓存密钥不是运行时证明：在比较运行器后端时记录所选的二进制文件和 node -v。

运行者的选择不取决于拉取请求作者。同一存储库 PR 使用配置的后端。当存储库变量不可用时，分叉首次尝试（包括首次贡献者）使用默认的 Blacksmith 路由；他们的 Node 规划器使用铁匠计时和相同的容量提升。分叉检查作业会保留逻辑 GitHub 条带布局，因为分叉无法安装调整一体化作业大小的可信缓存。运行器放置与布局和缓存权限是分开的。维护者接受了增加的铁匠支出。 Fork 重试路由至 GitHub- 托管运行器。当变量不可用时，存储库后端覆盖无法重新路由 fork 首次尝试。推送和手动调度不受影响。缓存信任是一个单独的、更严格的边界：精确的依赖关系恢复需要来自 openclaw/openclaw 的拉取请求，而普通的 CI 从不发布共享档案。独立的值得信赖的温暖者拥有出版物。

QA Smoke 仅将 8 类用于上游 main 推送和调度首次尝试的混合四部分计划，并具有明确的当前目标分类。完整的 24 场景配置文件和冷私有运行时构建在 7-GiB 内存上限下在两个可用 CPU 上传递，无需交换、跳过或 OOM 事件；峰值内存为 5.96 GiB。较旧的目标、其他配置文件、手动和发布运行以及重试将保留其现有位置。场景覆盖范围、工人限制、交错时间和截止日期均保持不变。观察部署后的实际工作持续时间和计费情况；仅靠较低的跑步率并不能节省成本。

该表列出了默认放置。在符合条件的混合首次尝试中，托管预算可以将security-fast和仅浏览器扩展E2E行移动到ubuntu-24.04；当可选入场关闭时，将应用默认的铁匠路线。

Control UI 单位行 （checks-ui） 保留在现有的铁匠 8 级上，进行规范的 hybrid/RunsOn 首次尝试，并具有现有的 20 分钟超时。可选的托管入场不会移动这些碎片。显式托管路由（包括重试和 github 覆盖）保留 35 分钟超时。覆盖范围、工作人员和每次测试的截止日期均保持不变。

基线棘轮和 Node 分片在预检后独立启动；最后一扇门仍然需要选定的棘轮才能通过。独立棘轮使用铁匠 4 级进行同一存储库混合首次尝试、自动主运行和承认的资格调度。 check-plan 在未设置、blacksmith 或 hybrid 后端（包括分叉 PR）的上游首次尝试中使用 16 类共享编译器快照内存。 GitHub 覆盖、重试、普通手动和冻结目标、RunsOn 规划器和其他存储库上下文保留托管规划。未设置或 blacksmith 后端的叉芯类型条带在当前自动首次尝试中也使用 16 级。它们的逻辑 GitHub 配置文件、五条带覆盖范围和仅恢复缓存权限保持不变；混合健康录取保留其现有的安置规则。编译器和 lint 行仍在等待其完整计划；合格的防护和依赖行在预检后启动。请参阅 入场测量和成本 。

当前上游核心 lint 条带在未设置、blacksmith 或 hybrid 后端（包括分叉 PR）的自动首次尝试中使用 16 类。相同的五个 fork 行仍然拥有其核心和扩展 lint 块；剩余的扩展块保留在组合的 check-lint 行中，该行已使用 16 类。独立的 check-lint-extensions-* 行仅限混合动力并保留其现有路线。 PR 缓存仅恢复。重试、普通调度、冻结目标、其他存储库和 OPENCLAW_CI_RUNNER_BACKEND=github 保留托管核心 lint；现有RunsOn及资格路线不变。

RunsOn 保留其独立棘轮和检查计划的托管位置，包括资格派遣。

同一存储库混合 PR 首先尝试使用现有串行编译器发现模式在托管 ubuntu-24.04 上运行 check-plan。完整快照对于该跑步者来说仍然太大。这会牺牲编译器执行时间，以避免在 type/lint 行开始之前进行第二次 Blacksmith 分配；主办策划者计入现有入场预算。分叉、其他后端、重试、push/schedule 和 manual/release 路由保留其现有的放置和发现设置。图形验证、选定的行和所有检查命令均保持不变。请参阅 测量和鉴定 。

健康的合格主推和 Windows- 选定的 PR 可以额外卸载 分配守卫 下的七个支票行。然后，仅 Main 就可以卸载 lint 和中央测试类型。每个决策都会消耗相同 45 行限制内的剩余容量；原来的跑步者仍然是后备。 Artifact 构建保留了 16 级：在预检和登机口开销之前，其托管最大值达到 898 秒。请参阅 路由测量和资格差距。

本机 Swift builds/tests、普通 CI iOS 构建阶段和外围扫描在 GitHub- 托管的 xcode-27 上使用 Xcode 27，预览 macOS 27 图像。此工具链更改保留了托管安置、职位数量、员工上限、覆盖范围和截止日期；它不添加铁匠注册。 Swift 源语言最低限度仍保持 6.3. 本机兼容性，完整的作业计时需要新映像上的证明。

iOS 屏幕截图碎片、商店发布及其仅屏幕截图操作在与可重用资格作业相同的预览图像上使用 xcode-27-xlarge。在 3-CPU、7 GB xcode-27 运行器上，iPad Pro 13 英寸模拟器耗尽了内存：simctl 和 XCTest 启动停滞了 60 到 100 秒，在启动或准备就绪时 iPad 捕获失败。屏幕截图使用没有 SimSlim 的库存模拟器。它为每种设备类型创建一个新的模拟器，然后在开始下一个之前关闭并删除它；仅屏幕截图作业接受选定的分支，而无需发布凭据。资格认证作业为其模拟器和隔离网关使用相同的较大运行器。库存资格使模拟器保持不变。在本机构建之后，每个手臂都会启动一个隔离的网关，并在启动新的模拟器之前通过 device.pair.setupStatus 准备其设置处理程序。状态调用会修剪过期的完成记录而不颁发凭证；应用程序使用的设置代码在启动后发出。同一个网关服务于实时配对、聊天和重新启动案例，然后在同一模拟器上的独立转录阅读器案例之前停止。这两个案件都必须在各自的期限内通过。

早期的托管路由验证使用 macos-26：重复的首次尝试导致 Blacksmith macOS 作业未分配，而其他 CI 作业已完成。在 run 33616182173 中，托管重试在八秒内分配了所有三个等待的 Mac 作业； Debug/simulator 作业在 15 分 31 秒内完成。该历史结果早于 Xcode 27。完整的手动鉴定仍然需要完整的本地证据。

Node 测试规划器仅标记运行真实本机 grep 夹具的分片。当选定的运行程序映像未提供 ripgrep 包时，这些 Linux 作业会安装该包。其他 Node 分片不支付该设置成本。

当前目标每个快速合约系列共享一个 checkout/setup。两个加权插件选择仍然作为单独的 test:contracts:plugins 进程运行；两个通道选择仍然运行单独的 test:contracts:channels 调用，每个调用保留其四个所属配置、四个项目插槽和每个项目一个工作人员。信封按顺序运行，任何非零退出都会在另一个信封被接纳之前停止作业。冻结目标保留其原始矩阵行并每行执行一个信封。运行器路由、缓存、工作预算和聚合门选择保持不变。在主运行33704083233中，单独的插件主体总计94秒，通道主体总计145秒；这些金额支持合并，但未衡量合并持续时间。

依赖项预热器在设置后立即发布已完成的 pnpm 存储，以免相关的 SDK、构建或转换工作失败。所有启用缓存的 Node 设置都使用相同的工作区本地存储路径，包括仅存储读取器；操作在缓存兼容性中包含该路径。 Pnpm 的副作用缓存携带本机安装后输出，例如 Matrix 加密的二进制文件和版本标记，因此兼容的热安装会跳过下载。冷缓存和更改的本机构建输入仍然需要上游资产。当该存储对于作业工作区来说是私有的时，Linux 设置使用硬链接，包括托管运行器上的仅存储恢复。这可以避免在没有克隆支持的情况下在文件系统上复制缓存的包。共享或外部存储以及普通 macOS 安装保留其配置的导入方法； freeze-lockfile 协调和生命周期脚本仍然运行。安装程序在激活 pnpm 之前恢复配置的存储根。同一工件包含固定的 pnpm 包装器和 toolchain/ 下的 Linux 本机可执行档案，由完整的 packageManager 引脚键入。 Bootstrap 在提取之前在私有暂存中检查其 SHA-512 哈希值；丢失或无效的档案会回退到运行程序映像，然后是注册表。精确的依赖关系存档包含相同的文件，并且依赖关系修复会保留它们。存储 v2 和精确依赖项 v4 条目重新种子一次以包含这些引导程序存档。缓存发布仍然属于每个后端上现有的温暖器。 Node 发现仅扫描工具缓存的可执行级别，在选择已安装的运行时之前避免捆绑 npm 依赖关系树。

在混合模式下，独立托管依赖项和代码预热作业填充 GitHub 的缓存后端。 Blacksmith 和 GitHub-hosted 缓存存档保持独立。有关完整的 Linux 和有界托管配置文件，请参阅 缓存所有权和种子选择。

Windows 依赖项缓存实验

正常 Windows CI 保持依赖项设置不被缓存。在 9 月 20 日的 基准测试 中，尽管重复使用了所有 1,453 个软件包且下载量为零，但 45.295s 的完整设置中位数与恢复商店的 52.738s 相比还是较低（+16.4%）。恢复763.8-MiB存档需要23.601/25.978/26.980s；第一个样本花费了 20.966s 来提取它。生产者设置和存档出版物添加了 62.527s 的工作工作。

所有七个本机作业都通过了，但工作流未通过资格认证：其减速器拒绝了报告的总数 RAM 中的 24-KiB 差异。这些测量使用原始收据，没有断言更改或重新运行。完全匹配的 RAM- 子集具有 47.369s 冷中值与 52.738s 暖中值 （+11.3%）；这种描述性比较并不能取代失败的资格。仅当考虑到恢复、提取、冻结协调和生产者工作后，完整的设置得到改善时，才重新访问缓存。

铁匠转轮能力

Npm 预检保留 blacksmith-32vcpu-ubuntu-2404。 Main CI 之前使用相同的类进行测试类型、核心类型条带和运行时拓扑检查，以补偿较小的交付机器。在 2026-09-01 容量检查 中，该标签是满足 OpenClaw 并行检查策略所使用的 8 个 CPU/24-GiB 阈值的第一个测量类别：

OS CPU 计数、亲和力、Node 和 CPU- 时间测量结果一致。来宾 cgroup 配额没有限制。提供商方造成不匹配的原因尚未解决；该表记录了观察到的容量，而不是铁匠广告中的规格或保证的分配。检查测量的容量，而不是整体发布加速或计费等效性。

紧凑型 Node 作业保留了规划者对两个子箱和铁匠工具或代理支持所有者的 32 类请求。 16 级交付了四个 CPU 和 15.42 GiB，迫使二子计划连续执行，尽管总包装预算不变。 32类是满足现有8-CPU/24-GiB准入门槛的测量分配。包装、检查姓名、计时身份、预算和工人限制保持不变；实际容量仍然是门重叠的。这会在班级之间移动现有作业，而无需添加跑步者注册或托管行。当前目标真实网关E2E采用16级；冻结或未分类的目标保留 32 级，如下所述。 Native CI 必须建立最终的执行和队列时间。

具有内存门控工人津贴的紧凑型团体也要求 32 级，包括独立的串行箱。隔离的网关组已请求八个工作线程，具有 28-GiB 内存层和两个工作线程后备。在主运行 35791016837 上，两个 8 级行接收了两个 CPU 和 7.66 GiB：它们的孤立子进程花费了 413 和 369 秒，完整的作业花费了 678 和 685 秒。 32 级飞机符合现有津贴。促销发生在包装后；文件成员资格、子排序、内存检查和后备工作人员仍然由同一计划者和执行者拥有。托管路由仍然使用工作流的信任和重试规则。这不会添加任何工作或跑步者注册。

原本请求 4 类的本机紧凑行现在在打包后请求 8 类。在容量检查中，两者都提供了两个 CPU 和 7.66 GiB，而 9 月 21 日运行的五次样本显示，4 级的分配等待时间中位数为 125 秒。逻辑打包类、子进程、工作限制和托管后备保持不变。这可以避免以更高的每分钟速率排队；组合包装和托管检查的变更必须能够节省净成本。

当前目标build-artifacts使用现有的16级。 受控测试箱证明 在 3ccc3710bd6 上在 229.3 秒内（252.8 秒，包括有效负载设置）在四个 CPU 和 15.42 GiB RAM 上完成了所有八个作业计算步骤， 12.59 GiB cgroup 峰值，没有记录的 OOM 事件。该证明保留了完整的并行验证者波，并通过了最终源、工作生成清理和内存事件检查。 SDK 声明生成现在使用一个编译器程序，具有现有的子堆预算和本机余量。冻结目标和丢失目标分类现在要求相同的 16 级；托管回退、作业计数、并发性和截止日期均未更改。记录的测量结果为测试的当前目标建立计算拟合，而不是历史目标或保证的完整操作持续时间。

checks-node-compact-large-5 和 checks-node-compact-large-9 仍保留 8 舱现有的基于推荐的促销。扩展包遵循规划器的运行器元数据：以前的bundle-16/bundle-25覆盖将在压缩后将旧的建议附加到不同的工作。 checks-node-compact-small-3、checks-node-compact-small-4 和 checks-node-compact-small-10 的前 32 到 16 覆盖被删除，因此这些行保留其计划员拥有的并行或加工能力。编号箱可以包含跨配置文件和修订版的不同工作；保留的紧凑建议使用 24 小时窗口，并且当这些垃圾箱发生变化时仍然需要基于所有权的更换。后来的建议确定了 16 级上 build-artifacts 的 CPU 饱和度。当前的完整作业持续时间和内存空间仍需要测量；较早的受控证明保留其原始来源范围。

当前目标 checks-ui-e2e-real-gateway 行使用 16 级。冻结或未分类的目标保留32级。规划器平衡第一行中的串行装置和审核的并行独立文件；第二个拥有剩余的并行文件。当通过完整的 manual/release 验证或直接桌面规范编辑选择时，第一行还拥有桌面传输证明。两行都保留现有的工作人员限制、测试前构建顺序、托管回退和测试截止日期。仅运行时准备将 SDK 声明生成和验证留给 build-artifacts。当选择通道时，拆分会增加一项工作和可能的注册，而普通 PR 继续忽略它。后端路由不变。精确头 CI 测量完整的行墙，包括安装和运输证明。

早些时候的 16 级尝试超出了 20 分钟铁匠的预算。在run 35120538555中，16级交付了4个CPU，并在1,227秒后被取消，而真实网关文件继续通过；最后一个文件在取消前已经过了 13 秒。设置、工件构建和桌面验证在浏览器套件之前花费了 6 分 31 秒。产能变更需要根据当前的准备和库存进行完整的工作鉴定；主办路线和所有考试截止日期保持不变。

铁匠真实网关分片有 30 分钟的作业预算；托管后备保留 40 分钟。在 run 38590548763 中，分片 1 在其 17 个文件中的 16 个完成后超出了 20 分钟作业限制。在 Vitest 之前，设置、构建和桌面传输证明消耗了 6 分 44 秒；最后传递的文件在取消前六秒完成。剩余的 API-key 文件没有完成的结果，因此这不会建立单独的测试挂起。范围津贴保留每个测试和子流程的最后期限，并且需要自然的完整作业运行来确定充足性。

在 run 38546577399 中，原生第二个分片花费了 3 分 13 秒的准备时间，其中包括 2 分 04 秒的构建，然后在 Vitest 中花费了 16 分 48.92 秒。所有 21 个文件和 48 个测试均已通过，但仅这些阶段就超出了之前的 20 分钟预算（不包括包装器启动或清理）。额外的十分钟为清理和工件上传留下了完成空间。

托管预算涵盖设置和测试。在run 34707873095中，尝试2，在浏览器套件开始之前已经过去了7分42秒；然后，20 分钟的工作限制取消了小部件案例之前正在进行的套件。托管预算涵盖完整的设置、私有工件构建和测试工作负载。单独的测试和子流程截止日期、测试库存、工作人员、路由和并发限制在两条路由上均保持不变。这不会添加任何作业或跑步者注册，也不会声称执行速度更快。

完整的CLI紧凑型箱在包装后要求32级，并使用fallbackMaxWorkers: 2测量的工人。串行自托管执行可以在观察到的 8-CPU/30.95-GiB 分配上接纳 8 个工作线程。托管、冻结、约束和重叠执行保留后备。仅处理 CLI 垃圾箱、串行同伴执行、打包和作业计数保留其现有策略。请参阅 Vitest 工人尺寸调整 。

早期的 16 类放置在相同的源、内存、启动缓存和案例库存下进行了受控的 2026-09-10 Linux Testbox 比较：12 分 20 秒至 14 分 15 秒，有两个可用 CPU，而 9 分 17 秒有四个可用 CPU，均由两个 ​​Vitest 工作人员进行。 307份卷宗、7977件案件全部被保留。这些测量不描述 32 类策略，也不包括 CI 设置、队列或伴随组。后来的 CLI 计时权重为 595 秒，完整的 CLI 配置在测量工作人员切换中保持不变。

后端路由仍然适用。混合重试和分叉重试保留其托管路由。普通手动 CI 调度仍以混合模式托管；完整发布验证的现有冻结目标 lint 异常仍然是单独的。 Npm 预检默认使用较大的 Blacksmith 请求，并保留其显式 use_github_hosted_runners 选项。

普通 iOS 烟雾 CI 为跑步者的架构构建应用程序和嵌入式 Watch 目标，使用相同的 iPhone 模拟器进行编译和语音清理测试。它省略了 CI 不消耗的编译器索引，并在 XCTest 启动之前完成模拟器准备。 Smoke 保留完整的测试结果和日志，但禁用详细的系统诊断收集：Xcode 27 在通过测试后可以花费 600 秒收集它。完整的手动验证保留了通用模拟器编译、详细诊断、发布设备构建和 lifecycle/UI/Watch 测试。冻结的目标保留其原始构建设置。

当前的主层 iOS 测试还构建应用程序和两个测试包一次，然后执行现有的语音、生命周期和双进程访问重启证明，而无需重建。他们通过运行器架构、Xcode 和依赖关系图恢复 Xcode 构建产品和 SDK 模块，并在源代码更改之间进行增量回退。共享 Swift 缓存所有者仅恢复字节相同的当前输入的时间戳；生成的版本元数据保持新鲜。成功的预定主运行单独发布这些档案，并具有四分钟有限的可选保存尾部。签名、测试选择器、串行模拟器执行和完整的 manual/frozen 构建均保持不变。独立的重启助手仍然构建自己的产品。 10 月 15 日的基线花费了 35 分 51 秒，其中包括冷 Xcode 应用程序构建中的 13 分 36 秒；第一次自然运行填充新的缓存，后续自然命中必须建立完整作业保存，包括存档传输。

计划主 CI 使用与主推送相同的自动运行器和依赖项缓存策略。 runson 配置保留计划工作的现有混合基线；只有合格的路径才会选择 RunsOn。手动调度仍根据现有策略进行托管，即使其调度 ID 类似于已停用的小时标记。原生跑步者标签和工人限制保持不变。

Runner 后端模式

macos-swift 通道构建一次 Swift 测试，并为每个作业运行一次每个测试。普通套件保留默认配置文件行为；渲染的快速聊天测试遵循新的默认配置文件进程，然后 AppState 隔离测试通过相同的资源拥有启动器在命名配置文件进程中运行。历史目标保留其原来的两个分区。每次启动都拥有一个私人住宅和一次性的、未锁定的默认钥匙串，直到测试进程组和输出管道关闭。 HOME和配置文件标记不隔离macOS服务；所有分区仅在一次性无凭证 macOS 工作线程上运行。当前支持启动器的目标将 Swift 测试并行性绑定到运行程序的逻辑 CPU 计数（上限为 12），用于自动运行、手动调度和重新运行尝试。只有早于资源所有者的冻结目标才使用串行回退。失败的测试会使作业失败，而无需在作业中重试。参见 native 测试安全性 。

存储库变量 OPENCLAW_CI_RUNNER_BACKEND 控制 ci.yml 的运行器后端：

可配置的重车道有build-artifacts和android。这macOS斯威夫特和iOS构建作业使用GitHub-主持xcode-27使用 Xcode27；截图碎片使用xcode-27-xlarge。重点关注的macos-node车道使用现有的GitHub-主持macos-15混合模式下的图像，具有相同的测试库存和两人限制。普通推送和计划运行openclaw/openclaw及其同存储库 PR，使用托管ubuntu-24.04为了preflight，所选的pr-failure-report， 和openclaw/ci-gate什么时候OPENCLAW_CI_RUNNER_BACKEND=hybrid。 Fork 的第一次尝试保留了现有的铁匠预检区和大门；他们的记者已经被接待了。全部workflow_dispatch qualification/release覆盖、运行组、重试和取消设置，blacksmith， runson， 和github后端保留其现有的路由。逻辑规划器配置文件、缓存信任、步骤和截止日期保持不变。这些控制措施为每个符合条件的人删除了三个铁匠任务PR每个合格的主要运行有两个，没有新的工作岗位。他们计入现有的托管预算；这是强制路由，独立于可选的卸载准入。托管作业仍可能延迟完成；看测量和估计成本. security-fast仅在符合条件的混合首次尝试中使用铁匠托管预算不能接受可选工作，并留在外面hybrid。它等待预检对选定的托管行进行计数，并且在预检失败后仍会执行，除非工作流被取消。安全挂钩使用固定安装的包和本地挂钩定义，因此它们不再初始化远程 Git 存储库。对于普通的同一存储库混合运行，security-fast仅当可选托管入场关闭时，才会保留铁匠控制分配。现有的保守注册保留不变；此路由更改不会断言组织范围内的空闲容量。混合动力紧凑型Node矩阵，最多80紧凑行加上单独附加的插件后备行，十三行checks-ui-e2e具有指定项目合同的目标矩阵，checks-ui-e2e-real-gateway共享其序列号的车道Chromium工作负载，四排QA上游自动运行的烟雾矩阵（手动调度的六行），两部分Windows矩阵，checks-ui， check-lint， check-test-types， 五个check-test-types-core-*行，check-dependencies， check-additional-extension-package-boundary， check-additional-runtime-topology-architecture， 和report-plugin-sdk-api-diff尝试时交给铁匠1。符合条件的二孩普通紧凑行请求blacksmith-32vcpu-ubuntu-2404；装有完整的垃圾箱agentic-cli团体请求blacksmith-32vcpu-ubuntu-2404规划后。其他紧凑小行保留blacksmith-4vcpu-ubuntu-2404，紧凑-大行保留blacksmith-8vcpu-ubuntu-2404，规划者测量的小队列促销保留了它们的8-vCPU 标签。在该集合中，只有浏览器扩展E2E行可能会移至托管Ubuntu；与...一起security-fast，预检最多允许下面两个可选行45-行托管限制。其他所有可配置的ci.yml车道保持混合托管，包括剩余的lint/check行、文档和Python技能。保留单独的 Opengrep 工作流程GitHub-主办。

仅调度插件 SDK API 报告请求 32 级。最近的 8 类作业暴露了两个 CPU 和大约 8 GiB 内存，低于并行渲染层。托管报告尝试也连续运行并超出了 20 分钟的作业预算。测量的 32 级暴露了 8 个 CPU 和大约 32 个 GiB，满足两个并发 6-GiB 渲染堆的现有 8 个 CPU/24-GiB 底线。资源保护、截止时间、托管覆盖和其他行保持不变。主要形式的资格发送保留了这份准确的 SDK 报告以及推送覆盖范围，并使用公认的跑步者后端。他们使用完整的验证层；主验证层保留用于普通的相同版本手动或计划验证。

RunsOn 资质

选择加入 runson 配置文件的计划源自 hybrid。它将三个 core-runtime-cron-parallel-* 子项提取到 c8i.8xlarge 上的一个串行作业中，该作业具有 32 个 vCPU、64 个 GiB、RAM、ubuntu24-full-x64 和 80 个 GB gp3 根。当前的 258 个文件 cron 库存保留了两个工作人员作业和组的上限。三个来源的铁匠工作保留了他们的其他孩子。 Hybrid 拥有共享的串行尾部拆分，并测量了九到四个工具包装，保留了子合同、工人和最后期限。 Broad-PR Node /紧凑计数在混合上为 98 /60，在 RunsOn 上为 99 /61，上限不变。未启用 NVMe、粘性磁盘、热池或测试清单更改。精确头比较分别在 396 秒、432 秒和 672 秒内通过了 Spot、Blacksmith 和 GitHub 上的 cron。两个本机工作流程仍然失败并且超过了十五分钟；请参阅 测量的路由成本和剩余的资格差距。

存储库后端值 runson 仅在首次尝试上游相同存储库 PR 时才承认此路由。存储库变量在资格验证期间保持不变。维护者可以改为调度 ci.yml，并将 runner_backend=runson、release_gate=true、pull_request_number 和 target_ref 设置为完整的当前 PR 头 SHA。工作流分支必须是PR当前的分支和头，并且现有维护者准入必须通过。该资格在 Blacksmith 和 GitHub 上添加了两个相同的 cron 控件，具有相同的固定 Node 版本和两名工作人员上限。它们计入最终的 Node 上限（此库存为 101/130），并且不包含在正常的 PR 计划中。有资格必须选择cron测试；否则，在分配比较运行程序之前预检会失败。资格使用配置文件的正常下游放置、只读缓存准入和 lint 分区。其预检将保持托管状态，直至授权成功并计入托管预算。仅发布 lint 和最小 Node 兼容性作业仍保留在普通手动验证中。普通的手动调度和不受信任或不相关的目标不能使用此覆盖。

对于主形测量，将 ci_shape=main 与相同的精确头 PR 输入设置并选择 runner_backend=hybrid 或 runson。这使用推送覆盖、70 行 Node 上限、Node 运行时和普通主 proof/native 选择。它省略了 PR 扩展回退和两个 cron 比较控件；它不添加仅手动发布的工作。原始 GitHub event/ref 仍然拥有信任、并发、缓存发布和来源。初始预检被托管并包含在测量的墙中。普通调度保留 ci_shape=default 及其现有行为。具有默认形状的显式混合限定使用 PR 覆盖范围。

RunsOn 每行使用一个不透明标签，具有唯一的 run/row 标识符：

runs-on: runs-on=${{ github.run_id }}-${{ matrix.check_name }}/family=c8i.8xlarge/cpu=32/ram=64/spot=true/retry=false/image=ubuntu24-full-x64/volume=80gb

现有的 GitHub App 处理此标签路由。它不需要操作员重新登录 AWS，但过期的操作员 SSO 会话会阻止当前管理、选定的 AZ 价格和拆卸验证。公共 AWS 提要提供未经身份验证的区域 Spot 参考：us-east-1 中此类型的 $0.6586/小时，获取于 2026 年 9 月 22 日 06：02：13 UTC。请参阅 价格来源、时间戳和测得的分配估算 。没有交互式登录是资格的一部分。

当现货容量不可用时，spot=true 保留提供商的自动按需回退。 retry=false 显式禁用自动中断重新运行：本机 retry=when-interrupted 可以在整个失败的工作流程尝试完成后重新运行失败的作业及其相关作业两次。这种恢复并未在最初的 900 秒墙内进行测量，因此中断的资格赛可能会失败。手动重新运行保留混合托管回退，并且不建立 Spot 恢复性能。请参阅提供商的重试合约和路由成本和资格差距。此选择加入路线不会造成十五分钟的中断安全索赔。

Hybrid 托管任务守卫

自动上游混合首先尝试检查最近的托管分配，然后再接受其他检查。主推直接晋级； PR 必须选择 Windows 覆盖范围和完整紧凑的 Node 计划，其中一行中至少包含 500 预测秒。承认的托管检查在 549 秒内完成，包括本机 PR 试验中的设置，在最终 Node 作业之前至少有 289 秒的时间。连续预测为入场楼层；实际设置、分配延迟和工作流程完成情况仍然需要测量。精确的计划、较短的连续行和聚合的两槽估计不符合条件。仅五个 Windows 分片不再建立旧的两分片延迟下限。仅快速范围、冻结目标、手动调度、重试和其他存储库保留其现有路由。

scripts/lib/ci-hybrid-hosted-health.mts 使用预检的只读操作权限。一个十秒的截止日期最多限制四个请求：过去一天内创建的最新十个主要推送运行，然后是来自最多三个新的合格运行的前一百个尝试绑定作业。服务器端日期过滤器可防止不受限制的历史记录列表忽略最近的匹配项。它仅对已知的托管作业进行采样，其唯一依赖项是预检。等待在作业创建和预检成功完成后开始，不包括依赖延迟。证据必须在三十分钟内提供；任何至少六十秒的分配等待、丢失分配的样本、格式错误的响应或 API 故障都会使新的卸载保持在 Blacksmith 上。该步骤报告原因、样本计数和最长等待时间，而不会公开请求诊断。

依赖关系、核心类型条带和运行时拓扑可以使用合格 PR 工作负载闲置范围内的可选托管容量。扩展包边界保留 Blacksmith，因为托管冷存档运行时间超过 22 分钟；他们编译的收据和依赖链接尚未跨结账根移植。准入保留了先前的边界行预留，因此此更改不会扩展其他卸载。 Main 还允许 lint 和central 类型。在 9 月 22 日的五次运行样本中，最大的独立托管检查花费了 664 秒；神器构建达到 898 秒，因此保留铁匠。这些观察取代了之前针对三十分钟主要目标所做的预测。当前的资格目标是在十五分钟内完成一次运行，包括预检、分配、设置和登机口；仅靠路线估计并不能确定这一点。普通同存储库混合预检使用托管Ubuntu；分叉和调度覆盖保留其现有路线。准入守卫现在拒绝等待 60 秒以匹配该目标； API and job deadlines remain unchanged。

这是对未来工作的录取决定。在快照之后开始的托管停顿仍然会延迟已承认的工作，并且现有的托管作业仍然处于暴露状态。检查本身可能会在飞行前增加长达十秒的时间。它永远不会更改存储库变量、迁移已排队的作业或重试失败的工作。

混合是正常的容量降级模式。如果铁匠宕机了：重新运行失败或卡住的繁重工作；它会自动登陆托管。在 Blacksmith 完全中断期间，记录是否设置了 OPENCLAW_CI_RUNNER_BACKEND 及其当前值，然后切换到 github 后备：

gh variable set OPENCLAW_CI_RUNNER_BACKEND --repo openclaw/openclaw --body github

github 覆盖还将完整发布验证编排、npm 资格、实时 QA、性能、包 Telegram、OpenWebUI 和发布运行时对作业路由到 GitHub- 托管的 Ubuntu。现有的显式托管运行器输入仍然受支持。跑步者排名发生变化；覆盖范围、工件身份、批准、工作人员限制和超时则不然。已经运行的作业不会移动。在解释托管结果时，请记住 OpenWebUI 磁盘要求和性能基准硬件差异。

主办ci.yml路径使用与手动调度和分叉拉取请求所执行的相同设置。分叉 PR 使用逻辑github即使存储库变量不可用，也可以检查配置文件，因此广泛的核心 lint 和测试类型工作负载会保留托管条带，而不是退回到需要可信缓存的超大一体化作业。 Fork 首次尝试使用 BlacksmithNode当后端变量不可用时标记，所以node_runner_backend使用铁匠默认设置，他们会得到其测量的时间和容量提升；分叉重试计划Node碎片与github。仅失败作业的分叉重试将其第一次尝试矩阵保留在托管运行器上，其中分片执行器将重叠的子项固定为一个。冻结目标通过以下方式选择加入此事件感知配置文件hosted-runner-profile-contract-v1；没有标记的目标保留其历史工作负载形状。仅限铁匠Docker并跳过粘性磁盘步骤，依赖项设置使用普通操作pnpm-存储缓存和低内存Android构建使用单独的 Gradle 进程。混合动力尝试——1铁匠Node高原通道从受信任的温暖器恢复准确的工作空间依赖档案。资格使用实际的运行器环境，因此托管通道和重试保留在普通存储缓存上。确切的密钥包括已解决的Node修补，OS、架构和语义依赖输入；不同的运行程序映像会安全地错过并遵循现有的商店安装路径。这Node工具链本身也通过它进行缓存API：铁匠的图像跟踪旧的跑步者图像快照，其工具缓存Node补丁（测量2026-08-16： 20.20.0， 22.22.0， 24.13.0）就坐在这个仓库的下面engines楼层，因此每个作业都会重新下载Node从nodejs.org.恢复是前缀键控的，并且保存带有已解决的补丁，因为精确的键击会抑制作业后保存，并且一旦楼层前进超过它，就会永远固定第一个有效负载。地板以下恢复的有效负载将被拒绝、修剪和替换。维泰斯特变换和Node编译缓存仍然使用上游 Actions 缓存API；他们的Linux-仅有的runner.os != 'Windows'条件不排除铁匠标签，并且受信任的温暖器单独发布每个后端本地受保护的种子。温暖者选择的跑步路线决定了该出版物是否到达铁匠的缓存或GitHub的缓存。核心 oxlint 保留五个固定托管条带，每个进程有一个 lint 线程。大型代理、网关、基础设施和UI目标在其分配的条带内的单独进程中运行，因此本机语义缓存在相邻目标运行之前被释放。这种隔离适用于显式核心条带调用。自动完整 lint，包括已发布的 Git 更新程序预检，即使在以下情况下也保留其原始的五个聚合核心程序：CI环境变量是继承的。普通非冻杂种push/PR运行组条纹1+2和3+4+5依次跨过两项工作。符合条件的首次尝试和认可的资格派遣使用铁匠16- 两个打包行的类；托管任务将他们置于可测量的关键路径上。第一排拿了621秒上8-类，包括568棉绒秒数；第二个后来超过了它15运行条纹时的分钟工作限制3， 4， 和5。两者都保留四个实际的 CPU 和现有的内存策略，以进行更大的有界检查。其他承认的不成对条纹使用8-班级。聚合门遵循上面的关键控制路由：普通的同一存储库混合运行使用托管Ubuntu，而现有的分叉、调度、资格、发布和其他后端覆盖仍然保留。可用的GitHub覆盖、重试、普通手动调度和其他存储库保留托管路由。失败的条带会停止其行。这github轮廓、冻结目标、手动调度和释放门保留了五个工作；GitHub插件条纹保留其现有所有者。插件 lint 所有权如下所述；脚本 lint 和可选UI和格式检查保留在现有的check-lint排。扩展类型感知 lint 发现extensions/tsconfig.json对于插件测试和帮助程序，保留导入的依赖项和共享的环境声明，而不添加不相关的core/UI/package源根。插件生产文件保留其现有的包边界项目。拉取请求中符合条件的核心源代码和测试更改会重用本地更改检查选择器。在当前目标上启用条纹支持github or hybrid，五个中的每一个check-test-types-core-*rows 验证完整的核心图边界，然后编译属于其指定条带的已更改测试的消耗图。条带成员资格在缩小之前分配，因此空的交叉点保持为空，并且联合保留每个选定的消费者。不明确的编译器所有权或删除的测试会选择这五个条带上的每个注册核心测试图。附加边界通道将其核心图检查转移到这些所需的类型行，并且check-test-types只拥有extensions/root/scripts尾巴。完整运行使用相同的五条纹，而无需缩小消费者范围。冻结目标保留两对成对的条纹行1+2和3+4， 有条纹5在中间一排。没有条纹支持的目标和全铁匠轮廓保持完整的中心路径。每个核心类型行最多保留两个并发编译器子级，每个子级保留一个构建器。核心检查保留独立资源策略；其余类型命令保留其现有环境。失败的边界或编译器在另一个命令开始之前停止其行。

agents-sessions 图拥有根 src/agents/session-*.test.ts(x) 测试和完整的 src/agents/sessions/、src/agents/session-maintenance/、src/agents/main-session-recovery/、src/agents/subagents/ 和 src/config/sessions/ 测试子树，将会话运行时、恢复、子代理和存储测试保持在一起。 agents-tools 图还拥有 shell/tool 测试、嵌套沙箱测试、托管工作树测试以及完整的安全和机密测试子树。 agents-other 图拥有剩余的嵌套代理测试子树和每个根级模型目录、选择、回退和身份验证测试 （src/agents/model-*.test.ts(x)），以及一些列出的根级准备运行时和工作区测试； agents-root 保留剩余的根级代理测试。 config-cli 图拥有配置、挂钩和 CLI 测试，但单独拥有的会话、守护程序、cron、程序和更新子树除外。 cli-update 图拥有 src/cli/update-cli/ 和根 src/cli/update*.test.ts(x) 测试； commands 拥有 src/cli/program/。根级网关会话测试属于gateway-root； gateway-server 拥有根级 server*.test.ts(x) 测试和完整的 src/gateway/server/ 测试子树。 gateway-methods 图拥有 src/gateway/server-methods/； gateway-other 拥有 src/gateway/worker-environments/、节点端 src/node-host/ 和 src/worker/ 测试子树，以及其余的嵌套网关测试。 infra 图拥有基础设施和媒体测试； state-logging 拥有审核、状态、日志记录和共享测试以及根级 src/infra/sqlite-* 和 src/infra/state-migrations* 测试。 plugin-sdk图拥有完整的src/plugin-sdk/和src/channels/测试子树； messaging 拥有自动回复和出站基础设施测试。 services-cron 图拥有 cron CLI（嵌套 src/cli/cron-cli/ 测试和根 src/cli/cron*.test.ts(x) 测试）和 cron 测试； services 拥有守护进程 CLI、守护进程、进程、系统代理、技能和基础设施更新测试。新的图形分割将附加到共享注册表中，以便现有的条带分配保持稳定。核心测试边界防护要求每个测试根在注册图上恰好一次，并报告超过 720 个根的图；根预算未通过本地检查，并在 GitHub 操作中发出警告。库存回归测试会在相同限制下发出警告，以便安排重新平衡。这些图保留了现有的条带分配和编译器并发性；移动的测试遵循新图表的条纹。更改测试选择仍然检查每个消耗图。

ui-e2e-chat 图拥有根级 ui/src/e2e/chat*.test.ts(x) 测试。 ui-e2e 图保留了其他 UI、E2E 测试和 ui/src/test-helpers/control-ui-e2e*.test.ts(x) harness测试。两者都保留 UI 引导程序和 Solid JSX 编译器设置。新图被附加到规范注册表中，保留现有的条带分配和五个 CI 类型检查行。

Android 承认上游 Blacksmith 推送和 PR 首次尝试中的所有四行，包括分叉 PR。托管路线、重试、手动调度和时间表保留两个。 Android Play 和 ThirdParty 行运行其单元测试。在正常的四行层中，Wear 还拥有第三方应用程序 lint，而 Kotlin-lint 行拥有 Play 应用程序和 Wear 共享 lint。当有多个本机调用时，每一行都保持独立、连续的 Gradle 进程，并通过现有的 openclawBuildTimestamp 属性共享一个 UTC 构建时间戳，从而避免仅因为稍后的命令启动而重新生成 BuildConfig。 Blacksmith 上的电话测试类最多在四个独立 JVM 中运行，受可用处理器限制，每个 JVM 现有 1 个 GiB 堆。每个 JVM 都会收到其可用处理器份额，因此其 GC 和内部池不会增加运行程序 CPU 预算。每个 JVM 中的类保持顺序；托管测试保留一个 JVM。完整的手动和历史兼容性任务清单保持不变。

任务范围的 Blacksmith 粘性磁盘在依赖项更改时保留 Gradle 用户主目录。 Gradle 拥有内容寻址失效以及未使用的缓存和包装器分发的定期过期；当依赖指纹发生变化时，CI 不会删除温暖的家。受保护的推送仍然是唯一的快照写入者，而拉取请求则消耗只读克隆。依赖关系解析保持在线状态，因此更改的依赖关系或冷快照可以填充丢失的工件。

在少于 24 个 GiB RAM 的主机上，串行插件 lint 运行默认使用八个目录块。自动 Linux CI 使用 16 个目录块，具有至少 4 个 CPU 和 15 GiB 已验证的物理和 cgroup 内存容量，包括祖先限制。未知或较小的容量、本地运行、Windows、显式插件条带和显式串行选择保留八个目录块。这会分摊重复的类型图启动，同时覆盖每个插件和根源文件。在 Windows 之外，显式全速或并行覆盖会保留之前的未分割工作负载。 Windows 块大小覆盖仅保留 Windows-。 Lint 仅准备 SDK 声明树；单独的包 TypeScript 边界检查仍然准备 SDK 和插件声明。

对于使用 github 配置文件的当前目标，插件 lint 块遵循六个现有作业的固定分割。五个 core-lint 作业中的每一个都运行其核心程序，然后运行其插件块； check-lint 拥有第六条带、脚本 lint 和格式。当前的混合目标使用三个托管的扩展 lint 行来完成完整的 lint 计划，保留两个打包的 core-lint 作业并保留脚本、可选的 UI 检查以及 check-lint 中的格式。相同的八目录块由现有的条带选择器重新分配，并保持单独的串行进程；每行在其块之前准备一次 SDK。这消除了三个签出、依赖项设置和 SDK 准备调用，而无需添加生产者作业或更改 SDK 编译器预算。有针对性的皮棉选择保留其现有的六条纹所有权。当安装的规划器回退到完成 lint 时，它会将减少的行数报告给现有的故障观察器；其六排的飞行前预订仍然保守。这避免了向最重的核心条带添加声明准备。每个扩展条带都使用现有的八个目录块、一个 lint 线程和串行语义程序。恢复的边界工件仍然通过现有的内容新鲜度检查；错过或更改输入会重建它们。 Preflight 在未更改的托管准入限制内计算其选定的行；任何新的负担得起的卸载都会移动现有的选定工作并且不会增加覆盖范围。冻结的混合目标、Blacksmith、发布门和没有扩展条带支持的历史目标保留其现有的插件 lint 所有权。

紧凑型 Node 规划器保留独立的 Blacksmith 和标准 4 核托管计时所有权。 github 配置文件和串行 hybrid 作业允许每个作业 210 预测秒，包括共享运行时准备。符合条件的普通混合垃圾箱使用以下更大的铁匠容量政策；文件分区、进程信封和显式工作引脚保持不变。 GitHub 仅将 1.6x 中值缩放后备应用于未测量的组。混合使用首次尝试 Blacksmith 估计和托管重试估计中较慢的一个（相对于不变的 150 秒上限）来划分组。这可以防止更快的重试估计导致缓慢的第一次尝试不可分割。其尝试 1 打包将现有的 0.87 规模应用于 Blacksmith 估计，并使用冷启动提示之前提交的测量结果。这些校准的预测与记录的包装器壁时间保持分离。改装可以在不改变跑步者政策的情况下改变紧凑型作业的数量和构成。直接采样提示涵盖了 doctor 和 cron-service 异常值。在混合中，未测量的 agentic-gateway-core-3 尾部在适用的串行或并行准入预算内保留其 140 秒回退。

包含 test/scripts/write-unified-entry-dts.test.ts 的混合紧凑作业在打包后请求 blacksmith-32vcpu-ubuntu-2404。在 run 35186413697 中，未更改的 120 秒缓存和冷输出测试在 8-vCPU 类的两个 CPU 分配上花费了 168.96 秒；每个测量的编译器阶段都成功返回。此升级保留了作业名称、文件分区、两个工作线程、串行执行、编译器调用和截止日期。 GitHub 模式和混合重试保留托管路由。最终精确头 CI 必须验证较大分配的时序。

Blacksmith 配置文件将现有文件分区器重新用于三个测量的串行异常值：chat/session 控制平面测试、第三个网关核心组和基础设施 storage/state 测试。他们完整的文件清单、配置所有权、工作引脚、构建先决条件和完整的时序历史底板保持不变。代理支持仍然是一项较大的跑步者工作。在捕获的 2026 年 9 月 2 日库存中，这些例外添加了 3 个紧凑作业，而插件整合则删除了 22 个。由此产生的广义 PR 预测为 103 个 Node 工作岗位；最后测量的运行使用了 121。源库存在这些观察之间发生了变化，因此实际的 CI 必须确定最终计数和挂壁时间改进​​。

GitHub 在打开另一个锚作业之前，对两个现有箱之间的单次交换进行拉请求和推包装检查。这可以避免当一个箱达到十组限制时的搁浅时间。替换箱和新入组都必须通过原来的入场规则，包括时间、先决条件和兄弟姐妹家庭限制。拉动请求锚点放置独立于托管工具库存；铁匠计划和混合计划保留了现有的包装。

普通非Windows CI目标为8分钟； Windows 仍必须通过，但位于此延迟目标之外。 210 秒扩展打包预算是估计值，而不是作业超时或测量的工作流程结果。预检、checkout/setup、排队和实际测试墙都重要。

动态子计时绑定到配置、环境、完整的父文件清单和有序子分配。人类分片名称在日志中保持可读；包装器计时跨度使用成员资格密钥。父总计只能从一个匹配分配的每个部分重建，因此来自不同分区的部分样本无法组合。每个子项都保留当前父项估计的文件加权份额，并且匹配的子项样本可以提高该下限。 GitHub 准入使用托管测量；混合入场使用按比例缩小的铁匠测量，而任一配置文件都可能需要更广泛的共享分割。失败的样本和超时重试的样本被排除在刷新之外。

具有注册文件列表器（CLI 进程、代理支持、网关方法、运行时配置、快速隔离单元）的整体配置组拆分为文件加权托管条带。 CLI 文件权重使用来自成功主运行的串行文件边界间隔，因此最长的过程夹具与剩余文件分开，而不会过度计算并发情况。代理支持和聊天还带有相对文件权重，以区分最慢的所有者；支持锚包括三个成功的主要运行的中值案例主体总和。子进程密集型工具系列使用 16 个文件加权条带，基于运行 33364935118 中观察到的 2,412 秒串行工作。工具文件权重包括 import/setup 时间；共享运行时先决条件会向拥有其使用者的条带收取一次费用。紧凑准入对每个作业收取一次最强的先决条件（运行时间为 100 秒，私有 QA 为 104 秒，具有托管扩展回退）。混合显式文件组将其运行时使用者放在一起，并将剩余的测试工作分开；固定的构建成本不会为不需要构建的文件创建额外的条带。 GitHub 工具保留将剩余文件打包到现有的 150 秒预算中。单个包装过程适用于完整成本和现有的兄弟分离规则；以后的再平衡不会使承认的上限失效。托管子分区保留非空文件分区并重新计算每个子分区的构建所有权。不可分割的文件可能会超出目标并保留其真实的预测。

如果 GitHub 拉取请求紧凑计划超过 96 行上限，则计划程序会在应用相同的打包规则之前对托管工具尾部重新分区一次。全尺寸块保持完整；只有最后的可分割尾部被分割成现有 150 秒预算的最多一半的部分，从而允许来自不同家庭的尾部共享工作。分离器重新生成会员绑定的计时标识，并保留测量的楼层、构建成本、运行器要求、工作引脚和串行隔离。最终的96排守卫仍然拒绝不合适的方案。铁匠和混合规划不变。

当代理支持成员资格发生更改时，其本机回退将在运行 33537556582、33537739443 和 33543106647 中的完整主运行跨度 478.25、450.21 和 418.13 中保留 479 秒。托管回退仍保留 253 秒。混合保留了观察到的原生回退，而不应用旧的整体规模；匹配子样本仍然可以提高文件加权父下限。当旧的 240 文件一代不再匹配时，这将测量的 241 文件库存保留在四个混合部分中。在铁匠资料中，整个支持小组现在请求 blacksmith-16vcpu-ubuntu-2404；其文件、进程范围和资源衍生的工作人员限制保持不变。

紧凑描述符计数和预测最大值随提交的测量而变化；连续剧TUI PTY距离描述符保持其不可分割的测量墙。在github托管模式紧凑作业运行；混合尝试1使用每一行的4-vCPU，8-vCPU，16-vCPU 或32-vCPU Blacksmith 标签，而混合重试使用托管运行器。每一个新鲜的Control UI E2E具有命名项目合约的目标计划使用 12 个组合加权分片加上一个浏览器扩展行，跨后端配置文件、尝试和冻结目标。有资格的Control UI行请求16-班级；浏览器扩展行保留8- 类，除非获准主办Ubuntu通过有界混合计划。没有指定项目合同的目标保留相同的组合Control UI命令及其历史宽度：Blacksmith planner 配置文件上的三个分片或托管配置文件上的十三个分片，以及浏览器扩展行。仅失败的作业重新运行保留之前发出的UI矩阵，包括旧的六分片计划；重新运行预检会选择当前宽度。Two/one-worker项目限制，25-分钟超时，最大并行14保守的注册上限保持不变。QASmoke 在正常的上游混合首次尝试中使用其现有的四部分计划，删除了两次重复的签出、依赖项设置和私有运行时构建。铁匠型材保留了四个部分；GitHub配置文件和新计划的混合重试、手动目标和缺少尝试元数据的运行保留六个。仅失败作业重试保留原始矩阵宽度。混合首次尝试使用铁匠；GitHub模式和混合重试使用托管运行器。所有场景、单独通道运行、并发限制、错开时间和截止日期保持不变；本机计时必须确定对完成时间的影响。QA策划者保留了最后部分的观察时间大约两分钟Matrix骑手在贪婪地分配主要场景之前，避免单独的运行成为尾部。Windows使用完整的两个包脚本清单作为输入scripts/lib/ci-windows-test-plan.mts，它发出最多五个不相交的整个文件行。当前测量的输入需要五行才能保持在420-第二次估计；四预测489每秒；五预测412每秒。共享项目分组减少了重复的 Vitest 启动，并且运行时消耗的文件共享一个准备行。每一行一次保留一个项目流程，并在读者开始之前准备好运行时先决条件。铁匠16-class 提供四个本机 CPU 和14 GiB并使用四名 Vitest 工作人员；托管后备保留一名工作人员。Windows调用显式地为其选定的文件启用文件并行性。单文件包合同和假定时器选择保留了自己的单工人预算。请参阅工人计数测量用于先前的两行测量和源标识。工作工件装置在其未分割的文件中保持共享。没有此规划器的历史目标保留两个包脚本行。max-parallel: 5允许重叠；实际的Blacksmith/hosted必须测量容量和队列时间，因为较旧的两个运行程序容量观察无法建立五个可用槽位。混合重试会在托管上保留发出的清单windows-2025。预计标准的个人构建速度会较慢4-核心托管跑步者。铁匠的跑步者注册预算与托管作业无关，但是GitHub-托管并发限制适用。

两个包脚本输入清单将小型项目放在一起：通用单元、网关、基础设施、运行时配置、媒体和 CLI 选择位于第一个清单中；快速单元、插件 SDK、共享核心和代理支持选择位于第二个。这种调整从早期的两项工作计划中删除了 8 个重复的项目流程，同时保留了所有 133 个明确目标。五行规划器通过共享项目元数据消耗它们的联合并重新组合执行，而不是将两个输入部分保留为作业边界。工具仍然可以被整个文件整除，因为它的编译器装置主导着执行；扩展包所有保留插件拥有的进程边界。 Windows 仍然证明本机路径大小写和别名、PATH/shim 解析、生成和进程树清理、计划任务服务、SQLite/file-locking 和发布行为，以及共享 CLI、包和运行时导入烟雾。

Mac Node 覆盖范围在现有跑步者标签上使用两个不相交的包脚本部分。提升生命周期、技能和剩余运行时项目共享第一部分，以便其子流程消费者重用准备好的工作人员一代；原生工件、打包和检查工具共享第二个。所有 26 个文件都保持被选中一次。聚合 test:macos:ci 命令运行这两个部分；具有三个部分脚本的历史目标保留三项作业，而没有部分脚本的目标保留一项完整作业。项目执行保持串行，现有的两人、CPU-clamped 三箱 Mac 夹具和两箱结账限制保持不变。在每小时运行 38823827091 中，前两部分分配在测试中花费了 247 秒和 465 秒，对同一工作输入图分别进行了 64 秒和 90 秒的编译。将其运行时使用者分组会删除第二个编译并将其他运行时项目转移到较短的行。每个 Node 设置的相同运行花费了 137-140 秒，而之前的三行基线则花费了 68-118 秒；未更改的工具文件运行速度也较慢，因此总作业时间不是分区形状的受控比较。本地每小时计时确定了最终的挂墙时间。

OpenClawKit 软件包通道为其禁用 Talk 的构建和默认特征测试套件创建了一个新的暂存目录。 SwiftPM 在启用 Talk 时重新规划和重新编译特征相关模块，同时保留该作业中的依赖性解析和检查工作。没有从早期运行中复制任何产品。 no-ElevenLabs 选择退出防护和完整的默认特征套件均保留；清理在成功、失败、取消或未选择的套件后运行。在每小时运行 38817599758 中，第二个新图在编译前在 16.9 秒内重复了 19 次依赖操作。使用一次划痕的本地仅编译重放消除了这些重复操作，并验证了在启用 Talk 的情况下重新编译的所有三个生产模块。托管已用节省来自下一个自然小时。

恢复后，恢复切换到 GitHub 回退之前记录的值。例如，使用以下命令恢复之前的 hybrid 设置：

gh variable set OPENCLAW_CI_RUNNER_BACKEND --repo openclaw/openclaw --body hybrid

仅当先前未设置变量时才删除该变量；删除选择默认的Blacksmith-first路由：

gh variable delete OPENCLAW_CI_RUNNER_BACKEND --repo openclaw/openclaw

ci.yml 不会检查 Blacksmith 或改变此变量。混合回退针对每个作业，并且仅当协调器重新运行工作流或选定的失败作业时才激活。

相关内容

• 安装概览
• 发布渠道