ci: 合入 main 只跑对应的成员,全量退到每周

[Sunrisepeak]

你问的那个:698b95ee 没改 CI 文件却跑了全量。原因不是文件,是事件类型 —— select 的第一行:

[ "${{ github.event_name }}" = "pull_request" ] || full "event=${{ github.event_name }}"

日志原话 full run: event=push,底下那套文件分类规则根本没走到。

前提不成立

这一刀切的理由是"push 没有可 diff 的 base"。实测不是这样:

• 本仓的合并都是 squash(main 上每个提交 1 个父节点)
• github.event.before 就是上一个 main
• before..HEAD 复现出的文件列表,和 PR 当时看到的一模一样

拿 698b95e 复跑新逻辑:

changed files vs 6e452b9d:   (十个,与 PR 逐个对得上)
→ selected members: redis-plus-plus redis-plus-plus-v133

而 #188 的 PR 运行当时选的正是 redis-plus-plus redis-plus-plus-v133。

改动

事件	行为
pull_request	三点 diff(自己的提交对 merge base)→ 选成员
push	两点 diff(这条分支上真正落下的)→ 选成员
schedule / workflow_dispatch	全量

schedule 和 workflow_dispatch 保持全量是有意的:它们表达的不是"有改动落地",而是"把所有东西查一遍"。

push 的两个兜底都倒向全量 —— before 全零(建分支)或那个对象不在历史里(force-push 丢了)时,没有可 diff 的东西,重跑好过猜。

五条路径都验过:

schedule           → FULL(event=schedule)
workflow_dispatch  → FULL(event=workflow_dispatch)
push before=0000…  → FULL(push with no predecessor)
push before=dead…  → FULL(push predecessor not in history)
push before=6e452b9d → SELECTIVE

定时:每天 → 每周

选择性测试结构上看不到的只有一件事:两个改动各自绿、落在一起互相踩 —— 两个 PR 的 diff 都没提到那个坏掉的成员,所以两个都选不中它。全量是这件事的网,现在它是唯一的网了,所以不能撤。

但这张网每天撒一次和每七天撒一次,抓到的是同一批交互;而全量已经不便宜:加了第二条 linux 工具链腿之后约 11 小时 runner 时间。改成周日 06:00 UTC。

手动触发本来就有(workflow_dispatch),想立刻验一遍不用等到周日。

省下多少

以 698b95e 为例:11 小时 → 两个新成员。日常合并基本回到分钟级,代价是跨 PR 交互最长延后 7 天暴露。

与 #189 的关系

两个 PR 都改 validate.yml,但落在不同的 hunk(#189 在 case 列表内部、shards_for 和 timings job;这里在 on: 触发器和 base= 那几行)。合并顺序无所谓。