A one-line change to a generated file in platform-objects costs ~60min of CI: 89 turbo tasks of affected tests #3692

实测数据,记录下来供 CI 维护者判断是否值得优化。不是故障报告 —— 行为是正确的,只是成本可能高于预期。

测到了什么

platform-objects 被绝大多数包依赖。改动它的内容会让 turbo 缓存对整棵依赖子树失效,于是 Test Core 的 Run affected tests (PR)(turbo run test --filter='...[origin/main]')要真跑几十个包。

本地用与 CI 相同的命令复现(#3670 分支,改动只有生成的翻译 .ts 文件):

Tasks:    89 successful, 89 total
26 个含测试的包全部通过,0 失败
耗时约 60 分钟

CI 侧同一 job 的耗时与之吻合。

为什么值得看一眼

触发它的改动可以非常小 —— #3670 是纯生成文件的翻译 bundle 更新,零运行时语义变化,却付了整整一轮全量 affected 测试。这类改动会随 pnpm i18n:extract 的常规使用反复出现(#3683 现在还把它变成了 CI 门禁,所以以后每次 schema 改 label 都会带出 bundle 改动)。

一个真实的副作用

耗时本身不是问题,难以与故障区分才是。同一个 job 在缓存热的 PR 上只要 7 分钟,冷的时候 60 分钟 —— 我在 #3670 上正是因为这个反差把它误判成挂起,做了一次无意义的 cancel+rerun,又推了一次并不需要的分支更新。最后是靠本地跑同一条命令才确认它只是慢。

如果这个成本是刻意接受的,那没问题;只是值得让人知道"慢"是预期内的,免得下一个人重复我的误判。

可能的方向(仅供参考,未验证)

• 对纯生成产物的改动走更窄的 filter(比如翻译 bundle 只影响消费它们的包,而不是 platform-objects 的全部下游)。
• 或者接受成本,但在 job 里打一行说明预期耗时区间,让"慢"可读。

前者是真优化,后者几乎零成本且直接解决误判问题。

复现

# 在一个只改了 platform-objects 生成文件的分支上
pnpm exec turbo run test --filter='...[origin/main]' --concurrency=2

Refs #3670, #3683。