CI 路由成本

根据测量的墙壁时间进行路由

使用 GitHub-hosted 运行程序进行适合工作流程剩余时间的独立检查。在测量的工作尾部威胁完成的地方保留铁匠。在为其分配生产层之前，按工作负载验证 RunsOn。在容量检查中请求铁匠8/16/32个标签交付2/4/8个CPU；标签不是工人计数。

该历史表将 11 次成功的 B1/R1 主要运行与 5 次后来成功的主要运行进行了比较：35679872894、35679457587、35678156129、35677164460 和 35675497006。这些是不同来源修订的纵向观察，而不是受控的提供商比较。值为完成作业秒数的中值[最大]；破折号表示未测量。 Placement描述了历史路由；当前的关键控制策略记录如下。现有信任、重试和 托管分配准入 仍然适用。

在此示例中，独立托管检查最多达到 664 秒。在共享预检和登机口之前，工件构建已达到 898 秒；他们保留了铁匠。只有门依赖于 build-artifacts：工作流程不包含串行构建到测试作业依赖性。

当前的包边界检查要求附加检查矩阵和共享 SDK 生产者中的 Blacksmith 16 级。冻结目标保留32级。现有的两个 CPU 保留允许两个编译器执行观察到的四个 CPU 16 类分配，而四个编译器执行八个 CPU 32 类分配。编译器、金丝雀、托管、重试、信任和缓存策略保持不变；这不会增加任何工作或注册。附加检查行有 40 分钟的截止时间； SDK 制作人保留自己的预算。

10 月 13 日的规模审查涵盖了过去 24 小时内的 2,063 个边界作业。在 32 个班级中，中位数和 p95 峰值内存分别为大约 31 个 GiB 的 26.35% 和 27.66%，没有报告 OOM。中位数和 p95 工作持续时间分别为 183 秒和 292 秒。这些测量结果支持较小的跑步者获得资格；他们不衡量其运行时间或节省的费用。

16 级 （36248684656） 的历史完整库存运行时间为 569 秒，32 级 （36269840991） 的历史完整库存运行时间为 301 秒。编译器优化在这些运行之间也发生了变化，因此它们不会隔离运行器的效果。在声称成本降低之前，先比较等效的工作负载和缓存状态：只有当运行时间增长不到两倍时，将运行速度减半才能节省资金。

精确的插件信封和未分割的两个工作人员命令信封现在使用配置、完整的文件清单和工作人员绑定的身份来提供现有的计时所有者。插件行序号从不识别工作负载。静态插件费率仍然是未衡量选择的后备方案，改装商在更换价格之前仍然需要两次独立运行。保守的单运行楼层在承诺的计时来源中明确标记。超过 300 秒的精确测量的多文件核心子级可以再次拆分，而无需重新定价其兄弟级或将不同的容量样本合并到父级中。单个文件溢出仍然可见。

网关方法更喜欢测量当前范围和工作线程策略，然后是该策略的完全所有者。在这些存在之前，匹配的老年工人范围和完整所有者测量仍然是准入楼层。更改两个关键限定符不得丢弃现有的所有者测量。

受进程限制的插件所有者还可以在信封更改期间保留每个文件的调用价格。这些价格与整个围墙的价格有着明显的区别；共享包装器开销只收取一次。只有每个流程都成功完成一系列收据并声明一份文件才符合资格。其他流程所有者和缺失的测量保持其现有的估计。

Telegram 过程重叠

具有至少两个单例进程的纯源 Telegram 数据库工作线程信封可以与当前自托管 Linux 运行器上的两个内部进程重叠。准入需要一个明确的当前目标（FROZEN_TARGET=false）、来自共享运行时选择器（包括 bun-compatible）的一个未更改的 Node 调用、两个工作线程、一个外部计划、调度程序拥有的缓存、至少两个实际 CPU 以及 7.5 GiB 有效内存。有效内存是物理内存和正有限进程约束中较小的一个。其他选择或容量不足保留一个内部流程。每个测试文件都保留自己的流程，并且焦点CI在失败后仍然停止承认新工作，同时加入承认的同行。

执行器报告实际的内部并发性，包括串行回退。它的值参与现有的受环境限制的计时标识。平行收据仅提供完整的信封墙；重叠的文件持续时间永远不会被求和并减去以得出包装器开销。在该确切策略具有合格的测量结果之前，布局将保留保守的序列估计。

199 个案例包络在 Linux 测试盒（仅限于两个 CPU 和 7.65 GiB）上使用两个进程连续测量 184.40 秒和 147.31 秒。另外三场资格重赛耗时 147.46、146.13 和 149.34 秒。峰值聚合内存保持在 4.51 GiB 以下，没有 OOM 事件且情况相同。全行预算仍然需要来自自然发生的 CI 运行的资格。

存储平衡还使用了 36 个配置范围的模块工作提示，这些提示来自精确测试的合并的未更改的两个工作人员重放。设置、收集和套件经过时间指南放置；最长的文件永远不会除以工作人员数量。单独的 20 秒津贴涵盖每个子项一次的编译器和包装器工作。这些保守的四 CPU 测试盒提示不是八 CPU 原生 CI 文件墙。现有的整体观察仍然具有权威性，未知文件保留先前的估计，工人政策保持不变。大量存储的孩子在分裂时保留其测量的 32 类分配；孤立并不意味着跑步者较小。

当成员资格发生变化时，编号紧凑的垃圾箱也会发生变化。匹配的后缀不会建立匹配的工作负载。完整的手动本机鉴定（包括 iOS 和 Android）并未在十五分钟内通过这些 Linux 测量得到验证。

关键路径上的托管分配

openclaw/openclaw 及其同一存储库 PR 中的普通推送和计划运行现在以混合模式将 preflight、选定的 pr-failure-report 和 openclaw/ci-gate 路由到托管 ubuntu-24.04。 Fork 的第一次尝试保留了铁匠的飞行前和登机口，他们的记者已经接待了。所有调度 qualification/release 覆盖、运行组、重试和其他后端模式都保留其现有路线。这将消除每个符合条件的 PR 的三个铁匠分配和每个符合条件的主运行的两个铁匠分配。在可选卸载之前，强制托管控件计数在现有 40 行基本阈值和 45 行准入限制内；没有新的工作或更高的限制。

10 月 15 日进行的 26 次 PR 运行样本记录了 148 分钟的飞行前等待时间，即每次运行平均 5.69 分钟、p75 12.9 分钟和最大 24.3 分钟； 26 人中有 8 人等了超过五分钟。 PR 墙上时间中位数为 35.6 分钟，而预检执行大约需要一到两分钟。一个单独的尾部对照样本等待了 27 分钟，完成了 12 秒的工作。这些观察结果确定了队列暴露；它们不测量托管路由更改的结果。

预计托管成本为每个同一存储库 PR 三到四分钟的标称舍入运行时间，三个控件的计算时间大约为两到三分钟。这是估计值，不是观察到的计费或已证明的工作流程加速。托管队列也可以延迟完成；在要求避免排队或减少工作流程占用时间之前测量第一次自然运行。繁重的作业、可选的卸载准入和所有验证命令保持不变。

以下 9 月份的观察结果解释了之前的路线决定，并保留作为历史证据。

在主运行35810905247（2026年9月23日）中，门在run_started_at之后1,068秒完成；运行元数据在一秒钟后完成。作业端点报告 105 行，包括跳过的作业，因此需要第二页来观察门。下面的每个创建间隔在前面所需的作业完成时开始，或者在预检时从 run_started_at 开始。

这是 416 秒的托管队列、190 秒的 creation/admission、460 秒的执行以及 2 秒的 Blacksmith 队列。当运行 35809764899 释放相同的偶数主奇偶校验插槽时，最初的 189 秒正好结束。它们是工作流程准入，而不是计划执行。计划者在飞行前 60 秒内；下游创建花费一秒。六个扩展 lint 行在最慢的 Node 作业之前完成并保持托管状态。

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

该链在托管排队上花费了 130 秒，在创建上花费了 2 秒，在执行上花费了 632 秒，在 Blacksmith 排队上花费了 16 秒。没有测试依赖于任一链中的工件构建。更改矩阵形状不会删除门的串行队列。

这些 9 月份的观察结果之前激励了 16 级的包装核心棉绒行和 4 级的门。 Core lint 保留了其测量的铁匠路线。目前普通的同存储库混合控件使用的是上面的托管路由； fork、dispatch 和 RunsOn 覆盖仍然存在。逻辑 li​​nt 分区、单个 lint 线程、扩展 lint 行、主奇偶校验槽、工作流依赖项和截止时间均保持不变。 RunsOn 的 cron 证据不符合 RunsOn 放置的 lint 或门。在观察到的托管等待达到六十秒后，现有的健康所有者还会拒绝可选的检查卸载，取代了以前的三分钟阈值。当分配消耗其执行裕度时，这可以保护中心类型和依赖行，而无需更改 API 截止日期或测试覆盖范围。第一个本地候选者对两个 lint 行都使用了 8 类。其 PR 运行 35813098351 在 785 秒内通过，但核心 lint 1 花了 621 秒（lint 本身为 568 秒），而托管基线为 398 秒（lint 为 350 秒）。 Core lint 2 花费了 353 秒，而托管则花费了 323 秒。该修订版仅为较重的行保留了四个实际 CPU，以避免将队列节省花费在较慢的执行上。按照历史列表费率和旧托管运行时间保持不变，16/8 拆分的成本约为 $0.2984，而不是两个 8 级行的 $0.1923。这些未经四舍五入的估计不包括最低计费和辅助费用；最终的成本和墙壁比较由本地测量而不是预测决定。

第二个打包行随后在运行 36422187813 中耗尽了 15 分钟的限制。受控的 4-CPU、16-GiB 上限租约在 137.37 秒内使用现有的较大运行者 Go 策略完成了其未更改的条带 3、4 和 5。现在两排都要求 16 级。此次促销活动不会增加职位或注册；在完整的 15 分钟期限内，第二行与 8 类相比最多增加 120 类 vCPU 分钟。租用测量不是本机 CI 计时结果。

修改后的 PR 运行 35814962786 在 16 级上测量核心 lint 1 在 275 秒，在 8 级上测量核心 lint 2 在 385 秒。较重行的参考计算约为 $0.1467，而其 551 秒 8 级主形观测的参考计算为 $0.1469，以及较早的 621 秒 PR 观测的参考计算为 $0.1656。这些是不同 CI 环境中的未舍入的完整作业成本，不包括最低计费和辅助费用。修改后的工作流程仍然未能通过 UI 测试，并且托管平均等待时间为 118 秒；这不是一个完整的十五分钟资格赛。

此更改在普通混合主和同一存储库 PR 上添加了三个实际的 Blacksmith 注册。分叉 PR 保留逻辑 GitHub 检查配置文件，该配置文件发出 5 个 core-lint 行，因此它们的增量可以是 6（包括门）。新的当前源审计在受支持的自动 main/PR 配置文件中总共有 71 个潜在自托管非 Node 行。该保守联合包括 5 个 core-lint 行、5 个 core-type 行、5 个 Windows 行和 13 个 UI E2E 行；它的轮廓最大值并不全部共存。六个扩展 lint 行保持托管状态。

保留 84 行非 Node 配额，在该并集之上保留 13 行。具有不变的 70/130 Node 上限和四个 main/21-PR 到达信封，4 × (70 + 84) + 21 × (130 + 84) = 5,110。这使得 890 人低于报告的每 5 分钟 10,000 人的注册限制 6,000 人的运营目标。这取代了过时的历史 80 + 3 + 1 解释，无需花费净空或更改矩阵上限。 Manual/frozen 发布作业和其他工作流程不在此有条件到达范围内；它没有建立完整的组织范围内的使用。

编译器规划队列

10 月 15 日分批后队列在 type/lint 入场之前仍然显示单独的铁匠队列。在 PR 库同时包含 908efae6fe8b 和 9915d01d074a 的前三个分配的规划器中，创建到开始等待的中位数为 559 秒，p75 为 637 秒。两个完成的规划器分别用了 113 和 151 秒。这些是不完整的自然运行观察，而不是整个工作流程加速测量。

同一存储库混合PR因此第一次尝试使用托管check-plan与其现有的串行发现模式。当前源重播在两种模式下都产生了相同的完整计划：批量发现16.7秒数和串行时间87.7在同一台 Mac 上几秒钟；最大限度RSS从16.5 GB to 5.65 GB. A Node 24.21.0 Linux重播也返回了相同的计划225秒下硬二CPU， 7-GiB限制无交换。它重复使用了相同的固定本机编译器ARM64； GitHubx64 延迟仍未测量。这些本地测量建立了执行权衡，而不是托管作业延迟。完整的图形验证器和所有compiler/lint执行所有者保持不变。在现有的可选卸载之前保留额外的强制托管行40-行阈值和45- 行限制。

只有计划者在行动；占用大量内存的 type/lint 工作人员保留其合格的跑步者类别。推送、调度、分叉、重试和 manual/release 覆盖保留其路由。自然CI必须建立新的计划者队列、完整的作业持续时间和工作流程挂起时间。设置加上 Linux 重播建议每个合格的 PR 大约有五到六分钟的托管跑步者分钟，取代一项铁匠 16 级作业；这是估计，而不是计费证据。该观察不需要调度或重新运行。

棘轮准入和Node测试

选定的基线棘轮和 Node 行在预检后独立启动。最后一道门仍然需要每个选定的棘轮才能通过。这保留了着陆的平行进入路径，并避免将棘轮设置移动到飞行前。

五个最新的阔绿色 PR 在 9 月 26 日采样截止点（36208949888、36208857347、36208617238、36208552952 和 36208291831）在托管 checks-fast-baseline-ratchets 中运行了 148-173 秒。结帐耗时 31-33 秒，依赖项设置耗时 27-52 秒，棘轮耗时 73-111 秒。那些历史 Node 行正在等待这项作业。当前的 Node 行从其旁边开始。预检耗时 89-120 秒，其中包括 48-83 秒的舱单规划；这些混合运行已经跳过了预检的精确依赖关系恢复。

同一存储库混合 PR 首次尝试、自动主运行和承认的资格派遣现在要求现有的铁匠 4 级进行棘轮工作。接近默认值 - Blacksmith 运行 36208877388 和 36209067188 测量完成棘轮工作分别为 85 秒和 91 秒。他们的设置时间为 12-15 秒，逐步调整时间为 39-40 秒。这些不同头部的观察结果预计棘轮墙要少 57-88 秒；它们并不能证明当前整个工作流程的节省。

使用较慢的 91 秒观察，该路线最多为每次符合条件的运行添加建模的 4 × 91 / 60 = 6.07 Blacksmith vCPU 分钟。它不增加任何工作岗位和一个实际的混合铁匠注册。该作业已属于默认后端下的潜在自托管非 Node 联合，因此现有的 84 行配额和 5,110 注册信封保持不变。托管路由仍适用于 GitHub 覆盖、混合重试、普通手动或冻结目标以及上游以外的存储库。棘轮检查、合并树验证、并行 Node 准入、依赖性协调和截止日期均未更改。

在单独的 check-plan 先决条件中，相同的五次运行花费了 165-209 秒。其编译器库存查询占用了 93-154 秒的实现步骤的大部分时间；每个缩小的 type/lint 行都会等待该结果。这些运行的中央测试类型检查在工作流程启动后 629-667 秒完成，因此仅推进 Node 准入无法满足 10 分钟 PR 目标。

因此，check-plan 在相同的混合准入下使用现有的 4 类，仅恢复实际自托管运行器上符合条件的相同存储库作业的确切依赖关系。该路线在现有的非 Node 储备中增加了一名铁匠注册。保留完整观察的 209 秒托管墙作为其保守的成本估算会增加 13.93 vCPU 分钟，或使用棘轮估算增加 20 vCPU 分钟。在此成本范围内不假设规划器加速。原生证明必须建立物化和全流程墙；编译器覆盖范围、选定的图表和所有托管后备保持不变。

广泛后备 PR 资格不选择 check-plan。其观察到的墙可以验证宽 Node 路径，但无法建立新的窄 type/lint 关键路径改进。该声明需要单独的本机运行，其更改文件计划选择此先决条件。

这两个控制作业更改仅适用于混合后端。 RunsOn 保留托管棘轮和检查计划，包括资格派遣。

RunsOn 仍不合格

on-demand Pilot 在 Blacksmith 上测量了两个关键的紧凑作业，时间为 561/816 秒，而 c8i.4xlarge 上为 755/1259 秒：慢了 35%/54%。在每个测试的工作线程数上，AWS 上的完整网关核心均失败。在 8 对 16 个工人的情况下，Cron 在 c8i.8xlarge 上从 156 秒扩展到 138 秒，在 c8a.8xlarge 上从 126 秒扩展到 110 秒，但缺乏匹配的 Blacksmith 控制。检查、工件构建、扩展和 UI 没有试点比较。

选择加入的 runson 配置文件源自混合，并将三个 core-runtime-cron-parallel-* 子项提取到 c8i.8xlarge 上的一项串行作业中：32 个 vCPU、64 个 GiB、RAM、ubuntu24-full-x64 和 80 个 GB gp3 根。在保留的 cron 比较清单中，所有 258 个文件都保留了其两名工人的工作和组上限，并且源 Blacksmith 工作保留了其其他子项。 RunsOn 在添加其 cron 行之前继承了 Hybrid 当前的拆分和打包。当前库存数量和定价记录在 测量紧凑包装 中；早期固定的朝九晚四的预测并不是普遍的结果。试点的 8 个工作人员、156 秒的 cron 墙仍然是历史背景，而下面完整的两个工作人员比较拥有可用的提供商证据。

兼容的 CLI 观测保留 558 和 703 秒预报，包括 1 个 60 秒设置余量。分离串行对并不会为每个不可分割的子级建立 600 秒的最长限制。符合条件的串行工具对现在分裂超过 600 秒全墙估计；打包单独的短作业使用 720 秒的入场限制。这些是安置估计，而不是提高的测试截止日期或对十五分钟工作流程墙的保证。

Qualification 运行 35702772380，在 84733d1a17a9a7321ac74099e421889099e411b4 尝试 1，在所有三个提供程序上运行相同的 cron 描述符。所有三个 cron 作业都通过了两个工人和一个串行子计划。 RunsOn 分配报告为 instance-life-cycle=spot；没有发生中断。下面等待的是工作创建开始，包括矩阵准入，而不是纯粹的提供商启动时间。

RunsOn 的工作持续时间比 Blacksmith 控件的工作持续时间短 36 秒，在该单一相同运行比较中减少了 8.3%。它不建立重复分发或限定完整的工作流程。新的 Blacksmith 子测量值是从现有源作业中删除的候选串行工作的 393.71 秒或 6.56 分钟，按历史 $0.064/分钟列表费率计算，大约为 $0.4200。控件的完整 7.2-minute 作业是一项附加的鉴定作业，而不是从生产中去除的数量。源作业保留其他子作业和设置。每个额外的铁匠 8 级分割都会增加估计 45-60 秒的准备时间；当前的库存会计显示如下。在声明整个运行净节省之前，必须包括运行时交互、这些添加的步骤和 AWS 分配成本。

早期的 基线运行 35688659765 在 252.63 组合子秒处测量了相同的 cron 描述符。较新的 393.71-second 控制取代了 4.21-minute 成本核算假设；这种差异是不将儿童持续时间预测与实际节省等同起来的另一个原因。

选择在上游同一存储库 PR 的第一次尝试上使用 runson 后端，或使用具有确切当前 PR 头的 维护者资格调度 。存储库变量保持不变。现有的RunsOn GitHub App为跑步者提供工作流程标签；没有交互式 AWS 登录是调度的一部分。最新的运营商身份检查失败，因为 AWS SSO 会话已过期，因此管理状态、拆卸和选定的 AZ 价格仍未验证。无需这些凭证即可获得公共区域价格信息。

职位请求 spot=true/retry=false。当容量不可用时，Spot 具有原生按需回退功能； 提供商的后备文档描述了额外的2-3秒，而不是完整的分配SLA。 retry=false 选择退出自动中断重新运行，因为完整工作流程恢复延迟尚未显示出适合原始的 900 秒墙。因此，中断可能会导致此资格失败。这是一个 Spot 放置实验，而不是一个安全的 15 分钟等级。

所选的 c8i.8xlarge 没有本地实例存储 NVMe。未启用粘性磁盘、热池、自定义映像或存储更改。 RunsOn 在兼容的实例存储类型（例如 c8id）上自动配置本地 NVMe；飞行员修正的覆盖验证器尚未提供该存储路线的实时性能比较。请参阅 RunsOn 本地 NVMe。

public AWS 现货价格反馈 在 2026 年 9 月 22 日 06：02：13 获取时，以 $0.6586/小时的价格报告 us-east-1 中的 c8i.8xlarge Linux UTC；它的 HTTP 最后修改时间戳是 06：01：21 UTC。这是一个区域参考，没有可用区域标识或假设的平均方法，而不是所选跑步者的计费费率。观察到的 Spot 实例于 08：06：00 UTC 启动，其作业于 08：12：57 UTC 完成：从启动到作业完成 417 秒，估算出 $0.076286以该参考汇率计算。这取代了之前的 156/187 秒说明性成本计算。

最终实例终止未经独立验证，因此 417 秒不是完整的计费生命周期。添加拆卸、存储、网络和控制平面费用。 $1.49936/小时按需参考仍然是 9 月 17 日的历史报价；在此资格认证中没有观察到按需回退。如果没有回退和中断频率，则不会声称预期的混合速率。早期大约 $0.09 的样本并不是固定的工作价格。

本机 中断恢复 仍然是未来的一个选项，需要测量裕度。 RunsOn v3.3 允许两次自动重新运行 和 retry=when-interrupted：它等待整个工作流尝试完成，然后重新运行失败的作业和依赖项。新推出的恢复容量是按需的，但 GitHub 可以分配现有的匹配 Spot 运行器。因此，入场必须考虑 first-attempt completion + retry delays + both failed/dependent replays <= 900s；仅仅将作业置于关键路径之外是不够的。 720 秒的第一次尝试还剩下 180 秒，已经少于恢复调度、分配和门之前测量的 396 秒 cron 作业。

报告观察到的中断并与此记录的提供商行为分开重试尝试。无容量回退或手动请求的重新运行不是中断恢复证明。在完全恢复适合原始墙壁之前，选择加入配置文件会保持自动中断重试禁用状态，并且不会提出中断安全 900 秒声明。

包装及成本算术

300 秒的变更扩展预算将相同的 119 个子信封合并为 40 个工作，而不是 9 月 22 日盘点库存中的 47 个。预计工作时间仍为 10,140 秒。每个作业的固定设置时间为 45–60 秒，扩展切片从 204.25–216 更改为 199–209 机器分钟：节省了 5.25–7 分钟。按照 $0.016/分钟的历史 8 级列表费率，即每大 PR 为 $0.084–0.112。公共托管执行没有计量 Linux 运行者费用；这种节省是那里的容量，而不是现金节省。

以下历史重播使用容量定价候选者的承诺 47b18faa725 库存，仅更改了扩展预算。这些条件计数描述了早期的实验，而不是最终重新设定的库存或组合分支的资格。

每个配置文件在 Node 矩阵之外还有两个 dist 描述符。 Main 不附加这些扩展信封。 Compact/PR/push/plugin 上限为 90/130/70/50。工作人员数量、断言、测试截止日期、运行时构建所有权和本机工作人员文件上限保持不变。工作流程不再将扩展捆绑包编号 16 和 25 提升为 16 级：这些职位现在包含不同的工作，并遵循其规划者拥有的 8 级路线。本机证明也必须测量这种容量变化。

预测可能是错误的。旧的 982 秒扩展作业包括数据库工作人员、Codex 和 Matrix 子作业，耗时 351/354/125 秒；候选人将相应的信封分别放入不同的包裹中。只有 Matrix 选择器是相同的。它的 27 秒估计值大大低估了观测到的 125 秒。保守地将该观察应用于候选包中的所有四个 Matrix 子项，大约需要 725 秒，其中包括 60 秒的设置，其他子项的不确定性仍然需要本地证明。

实测紧凑包装

混合布局重用 容量定价工作 中的共享工具估算器。它通过 readToolingFileTimings 读取提交的 Blacksmith 文件测量值，并将它们传递给现有估计器的可选文件映射参数。只有这个混合放置通道才会消耗额外的地图； RunsOn继承了混合计划。更广泛的定时有效负载和全局定价系数保持不变，因此该路线不会创建竞争性文件价格表。

当一个声明的工具文件、一个传递文件摘要、一个持续时间、匹配的报告者身份和成功退出一致时，共享收集器接受完整的单例调用持续时间。本机文件摘要保留优先级。六个单例文件价格是根据三个失败的工作流程中成功的作业和子项进行修改的；第七个保持在所有者 15% 的阈值内。七个范围内的本机 Testbox 文件更新填补了缺失的合格价格并更正了供应估算。失败的工作流程和取消的租赁清理永远不会提供完整的库存或修剪证据。

Packing 允许连续的 Blacksmith 8 级工作，现有的两人上限、编号的工具子项以及没有运行时构建先决条件。每个孩子都需要 完整的每个文件测量或精确的完整孩子本机观察 ，然后才能获得额外的打包工作。对于未知文件的默认两秒提示不能满足该要求。不完全衡量的工作保留其原始成员资格并获得其保守的报价成本和设置津贴。

完整的打包估计是 60 秒的设置加上现有所有者工作价格和标准组价格之和中的较大者，保留兼容的本机子观察作为下限。原生墙地板不会因工人比例而打折；共享文件估计器保持其正常的工人感知计算。每个包装作业必须适合 720 秒，包括设置，保留完整的孩子及其顺序，尊重兄弟姐妹家庭的分离并遵守其最后期限。较高的所有者价格不能被更快的历史样本所取代。

四个新的主要工具测试改变了早期的选择器。现在，同一估算器会对更改后的库存进行定价，而不是禁用包装批发。只有缺乏完整文件或本地证据的受影响作业才会被排除在合并之外。本机观察绑定到执行的配置、环境、有序选择器、子名称和构建模式；父计时密钥仍然是出处，而不是准入权限。因此，当同级发生更改时，未更改的子级可以保留其观察，而更改后的已执行合约会安全地使旧观察过期。

具有多个子项的合格串行工具作业拆分超过 600 秒整墙估计。完整的本地儿童总数在可用时推动了这一决定，而现有的工作预测仍然是一个下限；否则，标准估算将提供儿童费用。包装仍保留任何更高的标准价格。精确观察到的关键对也会分裂。运行时准备仅保留在需要的子级上，并且新分割的关键行无法通过该通道重新打包或收取另一个设置费用。 703 秒的 CLI 预测仍然是一个未解决的不可分割的尾巴。

本机校准

Linux 测试箱运行 35722202780 在 Blacksmith 8 级上使用源 2fd7485b450e12ef5574645d7b648d61ee5ce8a2，同时观察两个 CPU、两个工人和一个孩子。所有八名入选的孩子和跑步准备工作均顺利完成。封闭的工作流程在生命周期清理期间已取消 ****，因此它不是绿色工作流程或十五分钟资格认证。源对应保留了记录的跑步者标签夹具差异。

舍入的本机组件加上一个 60 秒设置，第一对产生 235/466 第二层，第二对产生 388/698 第二层。准备费用仅按 9-hosted-1 收取。新的完整 9-hosted-2 样本取代了没有失败的结果：之前失败的 631 秒观察仍然受到审查。四个包装儿童测量仅更新其新的精确指纹；最终包装也保留了较高的标准价格。这些是 child/build 收据和预测，而不是带有排队的完整 Actions 作业墙。

当前库存

Main 现在包括单独拥有的 runtime 发行层 ；其覆盖范围移动不是 R3 节省。在候选人重新基于 0a5b5381a26b 时，混合动力的广泛 PR 计划将两个关键对分开，并将 七个符合条件的工作打包为三个。删除四项设置可节省 3-4 分钟；两个分割添加 1.5–2 分钟，在运行时交互之前留下条件 1.5–2 铁匠 8 级分钟 /$0.024–$0.032。主要添加一个拆分及其设置。扩展包装保留了其单独受控的 47→40 作业比较。

不可变的九作业校准队列适合四个作业，标准预测为 629、539、662 和 672 秒。该群体检查政策；它不定义当前库存的作业计数。当前打包的 compact-small-20 预测为 617 秒，工具 compact-small-32 预测为 576.5 秒。已知最长的预测仍然是 703 秒的 CLI 子项。

紧凑计数包括 dist 描述符； Broad-PR Node 计数包括 40 个扩展行。 RunsOn 在混合计划中添加了一项 cron 作业。所有计数均保持在不变的 70/130/90 上限内。 Together、当前的 Node 和扩展包装从广泛的 PR 中删除了净九个设置：估计 6.75–9 铁匠 8 级分钟，或运行时交互之前的 $0.108–$0.144。主要添加一项设置，大约 0.75–1 分钟或 $0.012–$0.016. 这些计数和成本是规划器算术，而不是本机性能验收。最终测量结果记录在 PR #155403 中。

普通主还是不选AWS。认可的主形资格可以选择RunsOn，不包括比较对照。其初始预检将一直托管直至获得授权。资格赛在重播时保留其覆盖范围，同时使用托管路由、资源政策和截止日期；原始 GitHub 上下文继续拥有身份验证、并发性和缓存发布。

全程验收

基线运行 35679872894 花费了 21 分 18 秒：在预检创建之前花费了 5 分 20 秒，从预检创建到登机口花费了 15 分 58 秒。 32/16/8 级的铁匠级平均分配时间为 8/8/3 秒。工作流准入和跑者分配是不同的等待；将两者都包含在整个运行延迟中。

基线分配了 29/2/10 个活跃铁匠 32/16/8 级作业和 25 个托管 Ubuntu 作业。跳过的占位符不会消耗任何跑步者。 That is 258.15 Blacksmith machine-minutes；历史标签费率意味着 $13.84，而活动提供的预估价格为 $18-20。这些是定价假设，而不是发票。使用较旧的构建中位数，移动神器构建会增加一份铁匠工作和大约 4.67 铁匠分钟；扩展压缩仅适用于 PR。

完成任务需要在 900 秒或以下的时间内为每个更改的配置文件测量主形状和宽后备 PR- 形状的运行，每个铁匠类中值作业最多 60 秒。根据同一基线记录实际作业和步骤墙、总工作流程墙、班级计数和成本。规划器估计、减少的行数和成功的测试结果本身并不能建立此性能门。在存在精确的头部观察之前，路由和包装更改仍然是不合格的。

84733d1a17a9a7321ac74099e421889099e411b4 的两次本机运行都失败并超出了墙目标：

资格还使用了 Spot 上的 6.6 作业分钟数，以及上面的 $0.076286 启动到完成估算。它包括两个额外的 cron 控制和不同的调度准入，因此减去这些总成本不会隔离生产路由更改。铁匠 Linux 级别的中位等待时间为 PR 中的 12 秒，资格赛中的等待时间为 9-10 秒。 Windows 中位数分别为 48 秒和 61 秒；因此，资格赛也未能达到60岁以下二等舱的等待目标。 PR 中的成功作业尾数为 950 秒，资格赛中的成功尾数为 907 秒。通过 cron 控制不会将失败的工作流程转变为绿色或 15 分钟结果。这些运行早于当前校准的装箱候选，并且不对其进行限定。当前主形和宽形 PR 收货记录在 PR #155403 中。