fix(ci): 分片数要数腿,不是数 job —— #184 把 65 个成员跑成了 29 个

[Sunrisepeak]

#184 全绿,但它想验证的路径一次都没执行。 这是那个 PR 引入的回归,由我提出并修复。

症状

Plan the shards 用平台的矩阵条目数当分片数:

linux:$(jq -r '[.include[]|select(.platform=="linux")]|length' /tmp/matrix.json)

#184 之前这两个数恰好相等,所以一直没出问题。加了第二条工具链腿之后不再相等:linux 发 2 腿 × 3 片 = 6 个条目,而切分仍是 3 路,每个条目带的 shard 是 0..2。

于是 plan 按 6 路切,job 只消费 0/1/2 —— 分到 3/4/5 的成员一个都没跑。

后果

拿 #184 那次运行(31255335552)的真实数据复算:

shard	成员数
0	1	会跑
1	17	会跑
2	11	会跑
3	13	永不执行
4	9	永不执行
5	14	永不执行

65 个成员实际只跑了 29 个,与该次运行的日志逐片吻合(1 / 17 / 11)。

而且是静默的 —— 一个从未被分配的成员,和一个跑过并通过的成员,在 CI 界面上长得一模一样。

丢掉的名单里有:ffmpeg、opencv-module、opencv-module-dnn、opencv-module-unifont、catch2-v2、catch2-main、openssl。前面几个正是 #183 / #184 这条线要测的东西 —— 换句话说,那条新腿加进来之后,compat.ffmpeg 在它上面一次都没被编译过(三个 llvm shard 的日志里 Compiling compat.ffmpeg 计数均为 0)。

修法

读 .shards —— emit() 已经写进每个条目、job 自己也在用(matrix.shards)的那个值。plan 和消费方从此读同一个数,而不是两个碰巧相等的数。

macos / windows 不受影响也不需要改:它们仍是单腿,条目数正好等于分片数。这既是这个 bug 只咬 linux 的原因,也是它能在 review 里活下来的原因。

验证

拿 #184 那次运行的真实 matrix.json 跑 jq:

linux:   旧(条目数)=6   新(.shards)=3
macos:   旧=2            新=2
windows: 旧=2            新=2

plan_shards linux 三片合计:29 → 65/65,上面点名的成员全部归位。

教训

#184 的 PR 描述里我写了「预期第一轮不会全绿」,结果它全绿了 —— 我当时把这当成好消息。实际上全绿恰恰是警报:一条新增的、覆盖 41 个从未在该工具链下构建过的成员的腿,一次通过本身就该被怀疑。绿不等于跑过。