GitHub Actions：六个十秒作业为何计成六分钟

摘要

GitHub 对每个作业的不足一分钟部分分别向上取整。六个各十秒的完整作业，合计执行六十秒，却计为六分钟。
按当前标准 Linux 双核 x64 运行器每分钟0.006美元计算，六个短作业消耗0.036美元额度，一个恰好六十秒的作业消耗0.006美元；实际新增付款取决于包含额度是否已经耗尽。

工程师把检查拆成六个小作业，看上去只是把流程图画得细了一点。财务系统却可能看到六个最低收费单位。GitHub Actions 的一分钟，可以在同样六十秒的总执行时间里卖六次。

规则来自官方运行器价格表：每个作业使用的分钟和不足一分钟的部分，分别向上取整到完整分钟。不是等全部作业结束，把秒数加在一起，再统一取整。每画一道作业边界，就多开一只计费秒表。

固定一个私有仓库，使用同一种标准 Linux 双核 x64 运行器。假设六个完整作业分别精确执行十秒，总运行器时间六十秒。每个十秒进位成一分钟，合计六分钟。按目前每分钟0.006美元的单价，消耗金额为0.036美元。

再设一个完整作业，精确执行六十秒，只计一分钟，金额0.006美元。总执行秒数相同，计费量差五分钟，金额差0.03美元。这是以官方规则和假设时长构造的比较。真正合并作业，会改变准备、清理、依赖和运行时长，需要另行测量结果。

“完整作业”四个字不能省。一个命令跑十秒，整个作业可能还有其他步骤；命令用时不能直接拿来冒充作业计费时长。执行时间说明给出查看作业时长与计费分钟的入口。要把这一页接到当前运行器类别、单价和最终使用明细上，账才闭合。

按同一规则，六十一秒的作业计两分钟，六十秒计一分钟。跨过边界的那一秒，能让计费量减半。反过来，把十一秒优化成十秒，双方仍然各计一分钟。每省一秒钟，账单不会奉送同样的奖励。

这种阶梯价会改变优化顺序。已经很短的任务再快一点，可能只改善等待；刚超整数分钟的任务少花一点时间，却可能减少一个收费单位。只按“本次节省多少秒”排列成果，会把一些值钱的改动排在后面。

读者还要看第三只钟：开发者多久拿到结果。多个作业并行，可能缩短从开始到结束的等待，却不把各台运行器的执行时长变成同一段时间。逐项取整后相加，并另列原始时长之和，才能解释消耗。完成得早、运行器总用时少、计费分钟少，是三项可以交易的目标。

现行计费说明用金额表达方案包含的计算额度。符合条件的运行器使用，以及云端沙箱的计算与内存等用途，可以消耗同一份额度；合资格的用途之间没有优先级。每个计费周期开始时额度重置，耗尽后额外使用进入收费。

所以，上述0.036美元首先可能表现为包含余额减少。余额用尽后，才成为新增付款。仍在额度内的取整消耗，也会占用本可供其他合资格工作使用的空间。采购若只等信用卡多扣钱才看成本，等于把前一段消耗当成了没有用途的空气。

公开仓库使用标准 GitHub 托管运行器，独立于该额度免费；大型运行器在公开仓库中仍收费。这里的数字只针对已经固定的私有仓库和标准双核运行器，不能把不同收费类别混在一起，拼出一个虚假的省钱比例。

Actions 的组成说明把工作流分为作业和步骤。同一作业内的步骤使用同一运行器；不同作业有各自的运行环境，没有依赖关系时默认并行。当前文档也允许在一个作业内并行运行选定步骤，不能把“想并行”直接等同于“必须多拆作业”。

不同操作系统测试、环境分离、故障定位和更早返回结果，都是购买额外边界的理由。同一运行器可以在步骤间共享数据；这也让边界的改变超出单纯价格问题。为了少进位几分钟，删掉必要测试，或把需要分离的信任与权限混在一起，买到的成果已经变了。

实际收益还缺各作业真实时长、运行器类别、测试结果是否等价、等待时间、重跑情况和包含余额。成本的承担者倒很明确：是仓库所有者，不是按下执行按钮的人。画流程图的人在选择采购单位，收到总账的人可能远在另一个部门。每个十秒作业都可以很有用；每个完整分钟，都该说得清买到了什么。