Deploy to Production / pre-check (push) Successful in 42s
Deploy to Production / build (push) Canceled after 11m47s
Deploy to Production / deploy-edgeone (push) Canceled after 0s
Deploy to Production / deploy-upyun (push) Canceled after 0s
Deploy to Production / finalize (push) Canceled after 0s
Deploy to Production / notify-failure (push) Canceled after 0s
根因:pre-check job 的 outputs.can_deploy 绑定在 steps.repo-check 上, 而该步骤是无条件写 true;真正写 can_deploy=false 的是 steps.cron-check, 它写进自己步骤的 outputs,从未被 job 级 output 采用。 于是 build 的 if: needs.pre-check.outputs.can_deploy == 'true' 恒为真。 证据(run 8, event=schedule): - 日志 cron-check 已打印「距离上次提交: 9 小时 / 超过 1 小时没有新提交,跳过定时构建」 - 但随后 build 的 if 表达式求值 'steps.repo-check.outputs.can_deploy' 结果为 true,build 照常执行 后果:每天北京 09:00 无条件全量构建(build ~17min + finalize ~12.5min), 2 核服务器被白占约 32 分钟/天。线上不受影响(build hash 未变, COS/EdgeOne/UpYun 上传与部署均正确 skip)。 改动: - 合并 repo-check 与 cron-check 为单一步骤 decide,统一计算并输出 can_deploy - pre-check.outputs.can_deploy 改指向 steps.decide.outputs.can_deploy - 去掉原 cron-check 的 exit 0(避免步骤提前中断导致 output 丢失)