CI 路由成本

基于实测墙钟时间的路由¶

对于符合工作流剩余时间的独立检查，使用 GitHub 托管 runner。当实测作业尾部可能危及完成时，保留 Blacksmith。在将 RunsOn 分配到生产层级之前，先按工作负载对其进行资格评估。在容量探测中，请求的 Blacksmith 8/16/32 标签实际提供了 2/4/8 个 CPU；标签并非 worker 数量。

下表比较了十一次成功的 B1/R1 主运行与五次后续成功主运行：35679872894、35679457587、35678156129、35677164460 和 35675497006。这些是不同源修订版本下的纵向观察，而非受控的提供商比较。数值为完整作业秒数的中位数 [最大值]；破折号表示未测量。现有的信任、重试和托管分配准入仍然适用。

在此样本中，独立托管检查最多达到 664 秒。工件构建在共享预检和门禁之前达到 898 秒；它们保留 Blacksmith。只有门禁依赖 build-artifacts：工作流不包含串行构建到测试的作业依赖。

包边界检查现在在其路由选择 Blacksmith 时请求现有的 Blacksmith 32 类。在成功的 PR 运行 36248684656 中，其 16 类分配提供了四个 CPU，现有的双 CPU 预留准入两个编译器。该 527 秒的检查包括 257 秒声明准备和 268 秒编译全部 125 个插件。32 类提供八个 CPU，在相同策略下允许四个编译器。它不增加任何作业或注册。在观测到的 569 秒作业时长下，将类别加倍会增加 151.7 类-vCPU-分钟，或占该运行 12,921.2 总量的 1.17%。后续完整绿色运行 36269840991 测量到 301 秒和 160.5 类-vCPU-分钟，并检查了全部 125 个插件。上游编译器优化也有贡献，因此这不是孤立的 runner 提速。托管、重试、信任和缓存策略保持不变。

精确插件封装和未拆分的双 worker 命令封装现在使用配置、完整文件清单和绑定到 worker 的身份，向现有计时所有者提供数据。插件行序号从不标识工作负载。静态插件速率仍然是未测量选择的回退，且重拟合器在替换价格之前仍需要两次独立运行。保守的单次运行下限在已提交的计时来源中明确标注。精确测量的多文件核心子项若超过 300 秒，可以再次拆分，而无需重新定价其同级项，也不将不同容量样本合并到父项中。单文件超限仍然可见。

Gateway 方法优先使用当前范围和 worker 策略的测量值， 然后使用该策略下的完整所有者测量值。在那些测量值存在之前，匹配的旧 worker 范围和完整所有者测量值仍保持为准入下限。更改两个关键限定符 不得丢弃现有的所有者测量值。

进程受限的插件所有者还会在信封变更中保留按文件调用价格。 这些价格与整个信封墙钟具有不同的键；共享包装器开销只计一次。只有每个进程包含一个声明文件的完整成功串行回执才符合条件。其他进程所有者和缺失 测量值保留其现有估计。

Telegram 进程重叠¶

仅源码的 Telegram 数据库-worker 信封，如果至少有两个单例 进程，可以在当前自托管 Linux 运行器上重叠两个内部进程。 准入要求显式当前目标（FROZEN_TARGET=false）、来自规范运行时选择器的一个未更改 Node 调用（包括 bun-compatible）、 两个 worker、一个外部计划、调度器拥有的缓存、至少两个实际 CPU，以及 7.5 GiB 有效内存。有效内存是物理内存 与正有限进程约束中的较小值。其他选择或 容量不足时保留一个内部进程。每个测试文件保留自己的 进程，且聚焦 CI 在失败后仍会停止准入新工作，同时 加入已准入的对等进程。

执行器报告实际内部并发，包括串行回退。其 值参与现有的环境绑定计时标识。并行 回执仅提供完整信封墙钟；重叠的文件持续时间 永远不会被求和并相减以推导包装器开销。直到该精确策略 拥有合格测量，放置才保留保守的串行估计。

一个 199 用例的信封在受限于两个 CPU 和 7.65 GiB 的 Linux Testbox 上，串行测量为 184.40 秒，两个进程时为 147.31 秒。另外三次 合格重放分别耗时 147.46、146.13 和 149.34 秒。峰值聚合内存 保持在 4.51 GiB 以下，没有 OOM 事件，且用例相同。整行预算 仍需要来自自然发生 CI 运行的合格验证。

存储平衡还使用 36 个配置范围的模块工作提示，来自 对精确测试合并的未更改双 worker 重放。设置、收集、和 套件耗时指导放置；最长文件永远不会除以 worker 数量。单独的 20 秒额度每个子进程覆盖一次编译器和包装器工作。这些保守的四 CPU Testbox 提示不是八 CPU 原生 CI 文件墙钟。现有整个信封观察值仍是权威 下限，未知文件保留其先前估计，且 worker 策略保持 不变。重型存储子进程在拆分使其单独存在时保留其测量的 32 类分配 ；隔离并不意味着更小的运行器。

编号紧凑 bin 在成员变化时变化。匹配的后缀不能确立匹配的工作负载。包括 iOS 和 Android 在内的完整手动原生合格验证，并未由这些 Linux 测量证明能在十五分钟内完成。

关键路径上的托管分配¶

在 main 运行 35810905247（2026 年 9 月 23 日）中，门禁在 run_started_at 后 1,068 秒完成；运行元数据在 1 秒后定稿。jobs 端点报告 105 行，包括跳过的作业，因此需要第二页才能观察到门禁。下面每个创建区间都从先前必需作业完成时开始，对于预检则从 run_started_at 开始。

这是 416 秒的托管排队、190 秒的创建/准入、460 秒的执行，以及 2 秒的 Blacksmith 排队。最初的 189 秒恰好在运行 35809764899 释放同一个偶数 main 对齐槽位时结束。它们是工作流准入，而不是规划器执行。规划器位于预检的 60 秒内；下游创建耗时 1 秒。六个扩展 lint 行比最慢的 Node 作业更早完成，并保持托管。

在采样截止时最新的绿色 PR，运行 35811411598，在 780 秒内完成门禁（元数据在 781 秒定稿）：

该链路在托管排队中花费 130 秒，创建 2 秒，执行 632 秒，Blacksmith 排队 16 秒。两条链路中的任何测试都不依赖制品构建。更改矩阵形状不会移除门禁的串行队列。

因此，受信任混合首次尝试对两个打包的核心 lint 行请求 16 类，对门禁请求 4 类。逻辑 lint 分区、单个 lint 线程、扩展 lint 行、main 对齐槽位、工作流依赖和截止时间保持不变。托管仍然是独立廉价工作的路由。RunsOn 的 cron 证据不满足 lint 或仅 Bash 门禁的准入条件，因此这些工作负载保留已测量的 Blacksmith 路由。现有的健康负责人也会在观察到托管等待达到 60 秒后拒绝可选检查卸载，取代其先前的 3 分钟阈值。当分配消耗它们的执行余量时，这保护了中心类型和依赖行，同时不改变 API 截止时间或测试覆盖。第一个原生候选项对两个 lint 行都使用 8 类。其 PR 运行 35813098351 在 785 秒内通过，但核心 lint 1 耗时 621 秒（其中 lint 本身 568 秒），而托管基线为 398 秒（lint 本身 350 秒）。核心 lint 2 耗时 353 秒，而托管为 323 秒。该修订版仅为较重的行保留 4 个实际 CPU，以避免将排队节省用于更慢的执行。在历史列表价格和旧托管运行时间保持不变的情况下，16/8 拆分成本约为 $0.2984，而两个 8 类行则为 $0.1923。这些未四舍五入的估计不包括最低计费和附加费用；最终成本和墙钟比较由原生测量而非该预测决定。

第二个打包行后来在运行 36422187813 中耗尽了其 15 分钟限制。一个受控的 4 CPU、16 GiB 上限租约使用现有较大 runner 的 Go 策略，在 137.37 秒内完成了其未更改的条纹 3、4 和 5。两个行现在都请求 16 类。该升级不增加作业或注册；在完整的 15 分钟截止时间下，第二行相比 8 类最多增加 120 类-vCPU-分钟。租约测量不是原生 CI 计时结果。

修订后的 PR 运行 35814962786 测得核心 lint 1 在 16 类上为 275 秒，核心 lint 2 在 8 类上为 385 秒。较重行的参考计算成本约为 $0.1467，而其 551 秒的 8 类 main 形状观测为 $0.1469，先前 621 秒的 PR 观测为 $0.1656。这些是跨不同 CI 上下文的未四舍五入完整作业成本，不包括最低计费和附加费用。修订后的工作流仍然失败了一个 UI 测试，并有 118 秒的托管中位等待；它不是一次完整的 15 分钟资格验证。

该变更在普通混合 main 和同仓库 PR 上增加三个实际 Blacksmith 注册。使用逻辑 GitHub 配置的受信任 fork PR 会发出五个核心 lint 行，因此包括门禁在内其增加可能为六个。一次全新的当前源审计总计在受支持的自动 main/PR 配置中有 71 个潜在自托管非 Node 行。这个保守并集包括五个核心 lint 行、五个核心类型行、五个 Windows 行和十三个 UI E2E 行；其配置最大值并不全部共存。六个扩展 lint 行保持托管。

保留 84 行非 Node 额度，使该并集之上保留 13 行。在不变的 70/130 Node 上限和 4-main/21-PR 到达包络下，4 × (70 + 84) + 21 × (130 + 84) = 5,110。这使低于 6,000 运行目标的余量为 890，该目标来自报告的每五分钟 10,000 注册限制。这取代了过时的历史 80 + 3 + 1 解释，而不消耗余量或更改矩阵上限。手动/冻结发布作业和其他工作流在此条件到达包络之外；它并未确立完整的组织级使用量。

棘轮准入和 Node 测试¶

选定的基线棘轮和 Node 行在预检后独立启动。最终门禁仍要求每个选定棘轮通过。这保留了已落地的并行准入路径，并避免将棘轮设置移入预检。

在 9 月 26 日采样截止时间点，最新的五次广泛全绿 PR 运行 （36208949888、36208857347、36208617238、36208552952 和 36208291831） 在托管的 checks-fast-baseline-ratchets 上花费了 148–173 秒。检出耗时 31–33 秒，依赖设置 27–52 秒，棘轮检查 73–111 秒。 那些历史 Node 行等待此作业。当前 Node 行与其同时启动。 预检耗时 89–120 秒，其中清单规划占 48–83 秒； 这些混合运行已跳过预检的精确依赖恢复。

受信任的同仓库混合 PR 首次尝试、自动 main 运行和已准入的资格调度 现在为棘轮作业请求现有的 Blacksmith 4 类。附近的默认 Blacksmith 运行 36208877388 和 36209067188 测得完整棘轮作业为 85 秒和 91 秒。其设置 耗时 12–15 秒，棘轮检查 39–40 秒。这些不同 head 的观测结果 预计棘轮墙钟时间减少 57–88 秒；它们并不能证明当前整个工作流有所节省。

使用较慢的 91 秒观测值，该路径每条合格运行最多增加建模的 4 × 91 / 60 = 6.07 个 Blacksmith vCPU 分钟。它不增加作业， 仅增加一次实际的混合 Blacksmith 注册。该作业在默认后端下 已属于潜在可自托管的非 Node 作业并集，因此现有的 84 行配额和 5,110 次注册上限保持不变。托管路由 仍用于 GitHub 覆盖、混合重试、普通手动或冻结目标、不受信任的 贡献者以及非规范仓库。棘轮检查、合并树 验证、并行 Node 准入、依赖核对和截止时间均保持不变。

同样的五次运行在单独的 check-plan 前置条件上花费了 165–209 秒。 其编译器清单查询占据了 93–154 秒物化步骤的大部分时间； 每个收窄后的类型/lint 行都等待该结果。这些运行的核心 测试类型检查在工作流开始后 629–667 秒才完成，因此仅推进 Node 准入无法满足十分钟 PR 目标。

因此，check-plan 在相同的混合准入下使用现有的 4 类， 仅在实际自托管运行器上为符合条件的同仓库作业恢复精确依赖。 该路径在现有非 Node 预留范围内增加一次 Blacksmith 注册。 若将完整观测到的 209 秒托管墙钟时间作为其保守成本估算， 则增加 13.93 个 vCPU 分钟；若加上棘轮估算，则为 20 个 vCPU 分钟。此成本边界中未假设任何规划器加速。 原生证明必须确定物化阶段和整个工作流的墙钟时间；编译器覆盖率、 选定图和所有托管回退均保持不变。

广泛的回退 PR 资格认定不会选择 check-plan。其观测到的 墙钟时间可以验证广泛的 Node 路径，但无法确立新的收窄 类型/lint 关键路径改进。该论断需要一次单独的原生运行， 其变更文件计划选择此前置条件。

这两项控制作业更改仅适用于混合后端。RunsOn 保留 托管的棘轮检查和检查规划，包括资格调度。

RunsOn 仍未合格¶

按需试点在 Blacksmith 上测得两个关键紧凑作业分别为 561/816 秒，而在 c8i.4xlarge 上为 755/1259 秒：慢 35%/54%。完整的 Gateway-core 在所有测试过的 worker 数量下均在 AWS 上失败。在 8 对 16 个 worker 的情况下，Cron 在 c8i.8xlarge 上从 156 秒缩放到 138 秒，在 c8a.8xlarge 上从 126 秒缩放到 110 秒，但缺少匹配的 Blacksmith 对照组。Checks、制品构建、扩展和 UI 没有试点对比。

选择加入的 runson 配置源自混合配置，并将三个 core-runtime-cron-parallel-* 子作业提取到 c8i.8xlarge 上的一个串行作业中：32 个 vCPU、64 GiB 内存、ubuntu24-full-x64 以及 80 GB gp3 根卷。在保留的 cron 对比清单中，所有 258 个文件都保持其双 worker 作业和组上限，源 Blacksmith 作业也保留其其他子作业。RunsOn 在添加其 cron 行之前继承混合配置当前的拆分和打包方式。当前清单计数和定价记录在已测得的紧凑打包中；早期固定的九到四预测并非普遍结果。试点的八 worker、156 秒 cron 墙钟时间仍属历史背景，而下方完整的双 worker 对比则拥有可用的提供方证据。

兼容的 CLI 观测仍保持 558 秒和 703 秒的预测，其中包括一次 60 秒设置余量。将它们这对串行作业拆分，并不能为每个不可分割的子作业确立 600 秒的最大值。符合条件的串行工具对现在会在超过 600 秒完整墙钟估算时拆分；打包独立的短作业使用 720 秒的准入限制。这些是放置估算，而非提高的测试截止时间，也不是对十五分钟工作流墙钟的保证。

资格运行 35702772380，在 84733d1a17a9a7321ac74099e421889099e411b4 上的第 1 次尝试，在全部三个提供方上运行了相同的 cron 描述符。所有三个 cron 作业均以两个 worker 和一个串行子计划通过。RunsOn 分配报告了 instance-life-cycle=spot；未发生中断。下表中的等待时间是从作业创建到启动，包括矩阵准入，并非纯粹的提供方启动时间。

RunsOn 的作业耗时比 Blacksmith 对照组的短 36 秒，在这一次同运行对比中减少了 8.3%。这既不能确立可重复的分布，也不能使完整工作流合格。新的 Blacksmith 子作业测量值为 393.71 秒，即从现有源作业中移除了 6.56 分钟的候选串行工作，按历史 $0.064/分钟标价计算约为 $0.4200。对照组的完整 7.2 分钟作业是新增的资格作业，并非从生产中移除的量。源作业保留其他子作业和设置步骤。每次额外的 Blacksmith 8 类拆分预计增加 45–60 秒的设置时间；当前清单核算如下。在声称净整体运行节省之前，必须将运行时交互、这些新增步骤以及 AWS 分配成本计入在内。

较早的基线运行 35688659765在同一组 cron 描述符上测得合并子任务耗时合计为 252.63 秒。较新的 393.71 秒对照数据取代了原先 4.21 分钟的成本假设；这种差异也再次说明，不能将子任务耗时预测等同于实际节省量。

选择流程使用 runson 后端，基于规范、可信的同仓库 PR 的首次尝试，或使用维护者资格派发并指定当前 PR 的确切 head。仓库变量保持不变。现有的 RunsOn GitHub App 根据工作流标签提供 runner；派发过程中不包含交互式 AWS 登录。最近一次操作者身份检查失败，因为 AWS SSO 会话已过期，因此管理状态、teardown 以及所选可用区的价格仍未得到验证。公共区域价格源无需这些凭据即可获取。

作业请求 spot=true/retry=false。当容量不可用时，Spot 自带原生按需回退；提供商的回退文档描述的是额外 2–3 秒，而不是完整的分配 SLA。retry=false 选择退出自动中断重试，因为尚未证明完整工作流恢复延迟能适配原来的 900 秒墙钟时限。因此，一次中断就可能使该资格验证失败。这是一次 Spot 放置实验，而不是可抗中断的十五分钟级别。

所选的 c8i.8xlarge 没有本地实例存储 NVMe。未启用粘性磁盘、warm pool、自定义镜像或存储变更。RunsOn 会在兼容的实例存储类型（如 c8id）上自动配置本地 NVMe；该试点项目经修正的 overlay 验证器尚未提供该存储路径的实时性能对比。参见 RunsOn 本地 NVMe。

公共 AWS Spot 价格源在 2026 年 9 月 22 日 06:02:13 UTC 获取时报告 c8i.8xlarge Linux 在 us-east-1 的报价为 $0.6586/小时；其 HTTP last-modified 时间戳为 06:01:21 UTC。这是区域级参考数据，不含可用区身份标识，也没有假定的平均方法，并非所选 runner 的计费费率。观测到的 Spot 实例于 08:06:00 UTC 启动，其作业于 08:12:57 UTC 完成：从启动到作业完成共 417 秒，按该参考费率计算，估算计算费用为 $0.076286。这取代了此前 156/187 秒的示例成本估算。

实例的最终终止未被独立验证，因此 417 秒并非完整的计费生命周期。还需加上 teardown、存储、网络和控制面费用。每小时 $1.49936 的按需参考价仍是 9 月 17 日的历史报价；本次资格验证中未观察到按需回退。在缺少回退和中断频率数据的情况下，不声称任何预期混合费率。此前约 $0.09 的样本并非固定作业价格。

原生中断恢复仍然是未来选项，需要实测余量来支撑。RunsOn v3.3 允许两次自动重试（使用 retry=when-interrupted）：它会等待整个工作流尝试完成，然后重新运行失败的作业及其依赖项。新启动的恢复容量是按需实例，但 GitHub 也可能分配已存在且匹配的 Spot runner。因此，准入计算必须满足 first-attempt completion + retry delays + both failed/dependent replays <= 900s；仅仅把作业移出关键路径是不够的。一次 720 秒的首次尝试只留下 180 秒，这已经小于实测的 396 秒 cron 任务，且还没有计入恢复派发、分配和门控时间。

请将观测到的中断和重试尝试，与该文档所述的供应商行为分开报告。无容量回退或手动请求的重试并不能证明中断恢复能力。在完整恢复能适配原有墙钟时限之前，该选择加入的配置会保持自动中断重试禁用，并且不做出可抗中断的 900 秒声明。

打包与成本计算¶

300 秒的 changed-extension 预算将同样的 119 个子信封合并为 40 个作业，而在 9 月 22 日的计数清单中是 47 个。预估工作量仍为 10,140 秒。在每作业固定设置耗时 45–60 秒的情况下，扩展部分从 204.25–216 机器分钟变为 199–209 机器分钟：节省 5.25–7 分钟。按历史 8 类列表费率 $0.016/分钟计算，即每个 broad PR 节省 $0.084–0.112。公共托管执行没有按量计费的 Linux runner 费用；这一节省体现的是那里的容量，而不是现金节省。

以下历史重放使用容量定价候选方案提交的 47b18faa725 清单，并且只更改了扩展预算。这些条件计数描述的是更早那次实验，而不是最终 rebase 后的清单，也不是合并分支的资格验证结果。

每个配置文件在 Node 矩阵之外还有两个 dist 描述符。Main 不会追加这些扩展信封。Compact/PR/push/plugin 的上限仍为 90/130/70/50。worker 数量、断言、测试截止时间、runtime-build 归属以及 native-worker 文件上限均保持不变。工作流不再将扩展包编号 16 和 25 提升到 16 类：这些位置现在包含不同的工作，并走各自规划器所属的 8 类路径。原生验证也必须对这种容量变化进行度量。

预测可能是错误的。旧的 982 秒扩展任务包含 database-worker、Codex 和 Matrix 子任务，分别耗时 351/354/125 秒；候选方案将它们的对应包络放入不同的捆绑中。只有 Matrix 选择器相同。其 27 秒估计大幅低估了观测到的 125 秒。将该观测保守地应用于其候选捆绑中的全部四个 Matrix 子任务，得到约 725 秒（含 60 秒设置），其他子任务的不确定性仍需要原生证明。

实测紧凑打包¶

混合放置复用了来自容量定价工作的规范工具估算器。它通过 readToolingFileTimings 读取已提交的 Blacksmith 文件测量值，并将其传入现有估算器的可选文件映射参数。只有这个混合放置路径会消费该额外映射；RunsOn 继承混合计划。更广泛的计时负载和全局定价系数保持不变，因此该路径不会创建竞争的文件价格表。

当声明的一个工具文件、一个通过的文件摘要、一个持续时间、匹配的 reporter 身份和成功退出一致时，规范收集器接受完整的单例调用持续时间。原生文件摘要保留优先权。六个单例文件价格从三个失败工作流中的成功任务和子任务重新拟合；第七个保持在所有者的 15% 阈值内。七个限定范围的 native Testbox 文件更新填补了缺失的合格价格并修正了预留估计。失败的工作流和已取消的租约清理从不提供完整清单或修剪证据。

打包接受串行 Blacksmith 8 类任务，具有现有双 worker 上限、编号工具子任务且无运行时构建前置条件。每个子任务都需要完整的逐文件测量或精确的完整子任务原生观测，其任务才能获取额外打包工作。未知文件的默认两秒提示不满足该要求。测量不完整的工作保留其原始成员，并获得其保守报价成本和设置允许值。

完整打包估计为60 秒设置加上现有所有者任务价格与规范组价格总和中的较大者，并保留兼容的原生子任务观测作为下界。原生墙钟下限不按 worker 比例折扣；规范文件估算器保持其正常的 worker 感知计算。每个打包任务必须适合720 秒（含设置），保留完整子任务及其顺序，尊重兄弟族分离并保留其截止时间。更高的所有者价格不能被更快的历史样本替代。

四个新的 main 工具测试更改了之前的选择器。同一估算器现在对变更后的清单定价，而不是整体禁用打包。只有受影响的、缺乏完整文件或原生证据的任务被排除在合并之外。原生观测绑定到已执行的配置、环境、有序选择器、子任务名称和构建模式；父计时键仍然是来源，而不是准入权限。因此，当兄弟变更时，未变更的子任务可以保留其观测，而变更的执行契约会安全地使旧观测过期。

具有多个子任务的合格串行工具任务在超过600 秒完整墙钟估计时拆分。当可用时，完整的原生子任务总和驱动该决策，而现有任务预测仍作为下限；否则规范估计提供子任务成本。打包仍保留任何更高的规范价格。精确观测到的关键对也会拆分。运行时准备只保留在需要它的子任务上，并且新拆分的关键行不能由该路径重新打包或再次收取设置。703 秒 CLI 预测仍是一个未解决的不可分割尾部。

原生校准¶

Linux Testbox 运行 35722202780 在 Blacksmith 8 类上使用源 2fd7485b450e12ef5574645d7b648d61ee5ce8a2，具有两个观测 CPU、两个 worker 且一次一个子任务。所有八个选中的子任务和运行时准备均成功完成。外层工作流在生命周期清理期间被取消，因此它不是绿色工作流或十五分钟资格。源对应关系保留了记录的 runner-label 测试夹具差异。

四舍五入的原生组件加上一次 60 秒设置，为第一对产生235/466 秒下限，为第二对产生388/698 秒下限。准备只计入 9-hosted-1。新的完整 9-hosted-2 样本不替代任何失败结果：之前失败的 631 秒观测仍保持删失。四个打包子任务测量仅更新其新的精确指纹；最终打包也保留更高的规范价格。这些是子任务/构建回执和预测，而不是包含排队的完整 Actions 任务墙钟。

当前清单¶

Main 现在包含独立拥有的运行时发布层；其覆盖变化不是 R3 节省。在变基到 0a5b5381a26b 的候选上，混合的 broad-PR 计划分离两个关键对，并将七个合格任务打包为三个。四个移除的设置节省 3–4 分钟；两个拆分增加 1.5–2 分钟，在运行时交互之前留下有条件的1.5–2 Blacksmith 8 类分钟 /$0.024–$0.032。Main 增加一个拆分及其设置。扩展打包保留其独立的受控 47→40 任务比较。

不可变的九任务校准队列拟合四个任务，其规范预测为 629、539、662 和 672 秒。该队列检查策略；它不定义当前清单的任务数。当前打包的 compact-small-20 预测 617 秒，工具 compact-small-32 预测 576.5 秒。已知最长的预测仍是 703 秒的 CLI 子任务。

Compact 计数包含 dist 描述符；broad-PR Node 计数包含 40 行扩展。RunsOn 向混合计划添加一个 cron 任务。所有计数都保持在未更改的 70/130/90 上限内。合计，当前 Node 和扩展打包从 broad PR 中净移除九个配置：估计 6.75–9 Blacksmith 8 类分钟，或在运行时交互之前为 $0.108–$0.144。Main 增加一个配置，约 0.75–1 分钟或 $0.012–$0.016。这些计数和成本是规划器算术，不是原生性能验收。最终测量记录在 PR #155403。

普通 main 仍不选择 AWS。被接受的 main 形状资格可以选择 RunsOn，并排除比较控制。其初始预检在授权前保持托管。资格在重跑时保留其覆盖形状，同时使用托管路由、资源策略和截止时间；原始 GitHub 上下文继续拥有认证、并发和缓存发布。

整轮验收¶

基线运行 35679872894 耗时 21m18s：预检创建前 5m20s，从预检创建到门禁 15m58s。Blacksmith 类别中位分配为 32/16/8 类的 8/8/3 秒。工作流准入和 runner 分配是不同的等待；整轮延迟需包含两者。

基线分配了 29/2/10 个活跃的 Blacksmith 32/16/8 类任务，以及 25 个托管 Ubuntu 任务。跳过的占位符未消耗 runner。这相当于 258.15 Blacksmith 机器分钟；历史标签费率隐含 $13.84，而该活动提供的估计为 $18–20。这些是定价假设，不是发票。将 artifact 构建移回会增加一个 Blacksmith 任务，并使用较旧的构建中位数约 4.67 Blacksmith 分钟；扩展压缩仅适用于 PR。

完成需要针对每个已更改配置，测量 main 形状和 broad 回退 PR 形状的运行，且不超过 900 秒，同时每个 Blacksmith 类别的中位分配最多 60 秒。记录实际任务与步骤墙钟、总工作流墙钟、类别计数，以及与同一基线对比的成本。仅规划器估计、减少的行和成功的测试结果不足以确立此性能门禁。在存在这些精确 head 观察之前，路由和打包更改仍不合格。

在 84733d1a17a9a7321ac74099e421889099e411b4 上的两个原生运行均失败，并超过墙钟目标：

资格额外在 Spot 上使用了 6.6 任务分钟，并带有上述 $0.076286 的启动到完成估计。它包含两个额外的 cron 控制和不同的分发准入，因此减去这些总成本不会隔离生产路由更改。Blacksmith Linux 类别中位等待在 PR 中为 12 秒，在资格中为 9–10 秒。Windows 中位数分别为 48 秒和 61 秒；因此资格也未达到 60 秒以下的类别等待目标。成功任务尾部在 PR 中为 950 秒，在资格中为 907 秒。通过的 cron 控制不会将任一失败工作流变为绿色或十五分钟结果。这些运行早于当前已校准的打包候选，并不使其合格。当前 main 形状和 broad-PR 回执记录在 PR #155403。