北京
11个上传视频一夜之间从YouTube消失，我决定先暂停自动上传的定时任务。原本以为注释掉cron行是再简单不过的操作——以前也这么干过，这次却让另外两件事同时崩溃。
以下是问题所在，以及正确的暂停cron方式。
错误：注释掉cron行，却留下了key
原始yt-publish.yml长这样：
on: push: branches: [main] schedule: - cron: '0 21 * * 1,3,5'
我最初尝试暂停时改成了：
on: push: branches: [main] schedule: # - cron: '0 21 * * 1,3,5'
这样schedule:作为一个没有值的key保留了下来。在YAML术语中，schedule:没有值，是空标量（null scalar），这在YAML语法上是合法的——但GitHub Actions不接受。它的workflow schema要求schedule必须是一个序列（sequence）。空的schedule:key无法通过校验。
我在yt-publish-longform.yml里也犯了同样的错误。两个workflow现在都处于损坏状态。
失败是如何显现的
诡异之处在于：报错根本不说"invalid schedule"。GitHub的runner直接拒绝整个workflow文件，而且失败会出现在所有触发器上，包括push。
Actions选项卡显示：
运行状态：失败
运行时长：0秒
消息："此运行可能因workflow文件问题而失败。"
0秒意味着没有任何job启动。这是一个预解析阶段的失败。由于两个受影响的workflow都有push触发器和schedule触发器，接下来一个小时内每次提交到main都会显示红色检查标记。失败的workflow是上传暂停器本身，而不是任何实际的构建或发布workflow——所以起初那些红色提交看起来像是自己推送的内容出了问题，而不是yaml编辑导致的。
关键线索：0秒时长。任何真正的job失败至少需要几秒来分配runner。0秒失败几乎总是意味着workflow文件没能解析。
正确修复：注释掉整个schedule key
在不禁用其他触发器的情况下暂停cron，正确做法是注释掉key本身。GitHub的workflow语法文档要求schedule必须是序列，所以留下一个空的schedule:键必然导致校验失败。正确的写法是：
on: push: branches: [main] # schedule: # - cron: '0 21 * * 1,3,5'
把schedule这一行连同缩进全部注释掉，push触发器依然生效，cron定时任务被干净地暂停。下次想暂停GitHub Actions的定时任务时，记得注释整个key，而不是只注释cron那一行。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
