fix(ci): deploy-staging 全栈 push 被错误 skip — success() 改 !cancelled() #1581
Reference in New Issue
Block a user
Delete Branch "fix/deploy-staging-skip-bug"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
问题
当全栈 push(所有三个服务都有代码变更)时,
retag-staging-skipped的所有矩阵项都被 skipped(因为每个服务都有对应的 build-staging,不需要 retag)。Gitea 的
success()语义:所有依赖必须 success,skipped 视为不满足。结果:deploy-staging 被跳过,staging 环境不更新。
修复
!cancelled():只要 workflow 没被取消就运行,允许 skipped 依赖。同时删除两行误导性注释(声称
success()不阻塞 skipped,实际恰恰相反)。安全兜底
build-staging 真正失败时,workflow 不会被 cancel(只有手动取消或 concurrency 才会 cancel),所以
!cancelled()不会阻止 deploy。deploy 脚本里的docker pull+ health check 仍有安全兜底。【阻塞级判定】
📊 审查概览
🔴 阻塞级问题(必须修复)
success()修改为!cancelled()会改变 Job 的执行逻辑。原逻辑确保只有上游依赖(如build-staging)成功时才执行当前 Job;新逻辑仅检查流水线是否被手动取消,这意味着如果上游构建失败,当前 Job 仍会继续执行。这可能导致在构建产物不存在或损坏的情况下执行部署、测试等操作,引发误报或环境污染。!cancelled()过于激进,因为它同时也放行了“失败”状态。建议恢复success(),或使用always()并结合needs.<job_id>.result进行更精细的状态判断(例如:always() && (needs.build-staging.result == 'success' || needs.build-staging.result == 'skipped'))。💡 改进建议(不阻塞合并)
无
✅ 良好实践
无
🤖 由 AI 代码审查机器人自动生成 | 2026-08-31 11:04:29 | 模型:
🚀 预览环境已部署
🗑️ 预览环境已清理
PR #1581 已关闭或合并,对应的预览环境已被清理。