Files
blog/.github
zqlit 6838934fa5
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
fix(ci): 修复定时构建「无新提交则跳过」逻辑失效
根因: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 丢失)
2026-10-01 11:30:15 +08:00
..