Repository navigation
ci: 分离 scheduled run 到单独 workflow #1081
Description
Activity
@muzimuzhi scheduled run 失败传递给下游是什么问题吗？我不理解为什么要挑出这个问题开 issue。
scheduled run 失败，意味着当周正常运行 test 也会失败。定时任务起到了它的作用。
Fork repo 如果开启了 GitHub Actions，fork repo 里也会跑 scheduled run。如果失败，也会收到消息。
有的 fork 可能只想触发正常 ci，而不想跑 scheduled run/不想收到失败的 scheduled run 消息。
GitHub Actions 只提供了禁用某个 workflow 的功能。现在的配置，不能在 fork 仅禁止
on.scheduletrigger，分离到单独 workflow 后则提供了这个可能。@muzimuzhi 如果定时任务会失败，即便你不跑定时任务，非定时版本也会失败，而你一样会收到定时任务失败的邮件。定时任务只是把接到失败的邮件的时机提前而已。除非你永远不会 run 它的非定时版本，不然定时任务并不会增加你收到邮件的次数。而如果后者的前提成立，fork 为啥要启用 actions？改它增加复杂度而没有额外好处。这是一厢情愿的伪需求。
📋 需求评审 #1081
建议接受。该改动能让 fork 维护者单独禁用每周定时测试，避免无关的失败通知和 Actions 消耗，同时继续使用 push、PR 及手动测试。
项目 评估 业务价值 fork 维护者可以按工作流单独关闭定时运行，不必在“全部关闭 Actions”和“持续接收定时失败”之间选择。主仓库仍可保留每周缓存预热兜底。 预估成本 🟢 small 主要挑战:
- 拆分后需要保留定时测试当前使用的诊断模式，避免定时运行行为悄然变化。
- 新增的定时工作流也应纳入 CI 路径过滤范围，否则修改它时可能出现“工作流显示成功，但实际测试全部跳过”的情况。
schedule只能在默认分支上实际触发。建议为新工作流保留手动触发入口，以便合并后立即验证完整调用链。
影响范围:
- fork 中新增一个可独立禁用的定时工作流；push、PR 和现有手动测试入口保持不变。
- 主仓库仍按每周一 UTC 12:00 运行缓存预热兜底，不改变测试范围和频率。
- 不涉及宏包行为、用户数据或数据迁移；回滚只需恢复原定时触发并删除调用工作流。
🔧 技术细节
涉及模块: GitHub Actions 测试入口、可复用测试工作流、CI 路径过滤和相关 llmdoc 文档。
关键文件:
.github/workflows/test.yml当前触发配置test.yml向下层工作流传递事件名的位置_test-package.yml的事件名输入约定schedule对--show-saves的控制- 公共工作流改动的路径过滤清单
技术风险:
- 被另一工作流调用后，主工作流中的
github.event_name不再是schedule。如果只机械地增加workflow_call，下层测试会改用-H，丢失定时运行原有的--show-saves行为。建议给主工作流增加明确的布尔输入，由定时调用层传入，再向_test-package.yml传递schedule语义。 - 调用链会变为“定时工作流 →
test.yml→_test-package.yml”。该嵌套层级在 GitHub Actions 支持范围内，且当前流程不依赖需要额外转发的私密凭据，因此风险较低。 - 新定时工作流应加入
test.yml的_all路径清单，并用actionlint校验两份工作流。相关 llmdoc 中“test.yml直接响应 schedule”的描述也需要同步更新。
由 codex / gpt-5.6-sol 生成；本流程只分析，不自动修改代码。
@github-actions[bot] Bot 这就很扯淡了。既然已经意识到周期性 run 承担了 cache fill 的责任，它就更有必要存在而非允许取消。
总之，如果说不影响用户体验也不影响测试有效性仅仅影响测试结果可读性的「波浪号」事件还有些许价值，这个事我看不到实际价值。让我们关注一些真正有价值的东西吧。
定时任务只是把接到失败的邮件的时机提前而已。除非你永远不会 run 它的非定时版本，不然定时任务并不会增加你收到邮件的次数。
对于偶尔的、非日常的的贡献者/修改者：有一份开着 GitHub Actions/ci 的 fork repo，
- 在自己修改时，先与上游同步（触发非定时 ci），然后提交修改到 fork（也触发非定时 ci），最后贡献到 upstream 或作为长期分支在 fork 保留。
- 在自己没有修改需求时，希望能少接收无关信息。
这里的关键是「偶尔的、非日常的」。如果定时 ci 在所有 repo 里跑，上游 ci 一旦坏，这样的用户也会持续收到提醒。他们对上游 ci 失败不关心但会收到提醒，可能做更粗粒度的屏蔽（如禁止 fork 里的所有 ci），而非只是禁止 fork 里的定时 ci。
@muzimuzhi 偶尔的、非日常的维护者，为什么要持续开着 fork repo 的 actions？
@muzimuzhi 对于偶尔的、非日常的维护者，如果恰好在维护期间，收到定时任务的失败提醒是有意义的。这会提醒他们：上游有变更，需要注意。而不是把上游变更的影响与自身修改混为一谈，从而不易分析。如果不在维护期，那为啥不关闭 actions 或者干脆删掉 repo？
@muzimuzhi 偶尔的、非日常的维护者，为什么要持续开着 fork repo 的 actions？
开着没有成本。
关了可能带来不便：向 fork 提交后，没有触发 ci，检查发现是 GitHub Actions 没有开启。但开启后，不会自动触发错过的 trigger events，如果 workflows 没有设置
on.workflow_dispatch，必须新提交点什么来开启。这一段提交结束后，很容易忘了关闭 GitHub Actions。我自己以前也有这样的需求：fork 里定时 ci 失败一定会提醒我；upstream 里定时 ci 失败也会提醒我，因为我是最后修改相应 workflow 文件的人。
@muzimuzhi 我认为这件事情不难理解：从设计上，涉事 ci 的周级别定时任务和按 PR 和 push 触发的 run 是一个整体。
用你的话说，保持现状没有成本，改变反而有害。
关闭 issue。继续讨论也无法达成目的。
用你的话说，保持现状没有成本，改变反而有害。
为什么有害，有害在哪里？
在 fork 中开启 GA 但禁止定时 ci，会比在 fork 中关闭 GA 有害吗？
目前只有两个 workflow 包含定时任务
$ rg -F 'schedule:' .github/workflows .github/workflows/agentic-llmdoc-updater.yml 5: schedule: .github/workflows/test.yml 35: schedule:gentic-llmdoc-updater.yml对 fork 无意义（我也已经禁用），于是只有test.yml需要分离定时任务。@muzimuzhi 答案就在上一句话里。
（不是为了 push 拆分定时 ci）
想到，latex 项目在「定时 ci 容易失败」方面，是特殊的。
latex 生态的特殊性，打破了对 ci 可复现性的一般假设。因为 latex 的包管理器不能安装和 lock 任意版本、用户默认使用最新版，于是 ci 也不得不在最新版上测试（有固定版本的镜像，islandoftex 还提供了每周一发的镜像，但只在 ci 使用无法覆盖用户只用最新版的场景），导致 ci 的可复现性低（遇到包更新时 rerun 也可能失败），定时 ci 容易失败。
latex 的包维护者，也不得不更被动地处理其他包更新带来的兼容性问题。随着 ctex-kit 进入 vibe coding 时代 (b055af2) ，开发更中心化，真人在无 AI 辅助下对新增文档和代码内容基本看不过来，越来越只能做提 issue、提供用例、维护用户文档方面的事。从这个角度，说实话不光定时 ci 失败提醒，连带 issue 评论和 PR，对真人用户的可读性、可参与性都降低了。
也许未来 AI 更强更普及，这些不再是问题。或者等这一阶段的密集维护过去，会回归到一种平衡。
@muzimuzhi 密集维护显然已经过去了。我的兴趣都开始转向逆向开发了。如果没人报 issue 或者定时任务没报错，我才不想看 ctex-kit 呢。（狗头
Vibe coding 的遗产会长期存在了，而且你付费的 AI 哨兵也还尽职着
@muzimuzhi 没有理解你所谓的 vibe coding 的遗产是什么。它是什么坏东西吗？
AI 哨兵还在尽职尽责，是什么坏事情吗？
遗产有好有坏。（更新：也可以比成，遗产是好东西，但使用遗产要交遗产税/修改它们要付出更多的理解成本，包括但不限于适应 AI 的常用词汇。）AI 哨兵在尽职尽责是好事，感谢你的付费付出。
有哨兵在，fork user 收到定时 ci 失败的消息后，需要做的很少了。想到 gitlab 的一个功能，一个失败的 ci 后面修复了，会收到修复的（邮件）通知，也许能节约「看到失败消息、计划行动的」用户的时间。
或者等这一阶段的密集维护过去，会回归到一种平衡。
这里的「或者」，是指 AI 没有变得更强更廉价普及，于是不是人人能用上；「回归」，是在「或者」前提达成时，我设想的一些未来的变化，比如厚重的 code comment 有所简化，方便人类读者。
之前就想问，comment 编辑后、甚至多次编辑后，你那边看到的是哪一版？因为好像你不是在 github web/app 上回复的。
@muzimuzhi 让我说得直接一点：我不需要任何人感谢。我自己做的很开心。
而且，此外，既然如此，你把「vibe coding 的遗产」之类的时髦词汇抛出来，是想表达什么？
至于 fork user 的问题，我认为之前已经讨论得相当充分了。退一万步说，就保持现状，怎么了？它至多一周发一封邮件，是有多大的打扰？如果嫌烦，给它关掉，有多麻烦？
@muzimuzhi 我回复的是未发生任何 edit 之前的原始版本。
@muzimuzhi 说到底，从根源上，既然有开关可以关闭，那么 fork repo 的至多一周一两封邮件的频率我不认为是什么大问题。
如果再考虑到，对于维护期的 fork repo，这类邮件也提供了有效信息，它是不是个问题都值得商榷。
我回复的是未发生任何 edit 之前的原始版本。
统计了在这条发出之前，我的评论修改比例，4 条修改过 / 总计 10 条。
@muzimuzhi 通常是看不到的= =……
基本上工作都在命令行 + GitHub bot (on Telegram)而且，此外，既然如此，你把「vibe coding 的遗产」之类的时髦词汇抛出来，是想表达什么？
完全不觉得时髦，碰巧这么使用了而已。
至于 fork user 的问题，我认为之前已经讨论得相当充分了。退一万步说，就保持现状，怎么了？它至多一周发一封邮件，是有多大的打扰？如果嫌烦，给它关掉，有多麻烦？
我在 #1081 (comment) 一开头就写了「（不是为了 push 拆分定时 ci）」。后面回复里我顶多只是提到它，没有想推动它的想法。
从 #1081 (comment) 开始，就只是闲聊而已，只是刚好发生在、发布在这个 issue 下面。
我不知道因为什么差异或原因，导致你对我提到 fork user 角度的想法如此敏感，要连续发反问句。我们都别这么敏感。
如果再考虑到，对于维护期的 fork repo，这类邮件也提供了有效信息，它是不是个问题都值得商榷。
发现你没有 fork ctex-kit，都在主仓库工作（我之前就关注到你的（AI 的） feature branch 都在主仓库，但没查看你有没有 fork）。这应该是差异来源之一。github docs 对两种工作流都有提到，"Fork and pull model" vs "Shared repository model"。
我们都别这么敏感。
我的部分是指，我对网络发言中的反问句敏感。
@muzimuzhi 我没有 fork ctex-kit 说明了什么问题呢？——啥也说明不了，因为我 fork 并维护着其他项目。
@muzimuzhi 我对「从 fork user 的角度出发的问题」没有任何偏见，也没有敏感。
我只是单纯觉得，这个问题已经讨论清楚了，没有继续讨论的必要。在我眼里它甚至不是个问题，更不用说是一个「大问题」。进而，「我很烦」。
从 #1081 (comment) 开始，就只是闲聊而已，只是刚好发生在、发布在这个 issue 下面。
我只是单纯觉得，这个问题已经讨论清楚了，没有继续讨论的必要。在我眼里它甚至不是个问题，更不用说是一个「大问题」。进而，「我很烦」。
所以是这个原因。我刚刚都想发个笑话轻松一下了。
目的：在 fork 中，fork owner 可只禁用 schedule-only workflow，而保留其他 workflow。
现状：如果 fork 想开启 GitHub Actions，就不得不同时接收 scheduled run 失败的消息。
方式：
on.schedule、添加on.workflow_call例子：
muzimuzhi/latex-zutil中的check.yml、lint.yml和schedule.yml。