GitHub Actions工作流运行限制35天，是否有可行解决办法？

GitHub Actions 单工作流的35天运行时长是官方硬限制，无法直接延长，但针对你覆盖SIT>UAT>Prod的长周期CI/CD场景，可以通过以下方式规避这个限制：

• 拆分阶段为独立工作流
  将整个流程拆分为三个独立的工作流：SIT部署工作流、UAT部署工作流、Prod部署工作流。每个工作流仅负责对应阶段的任务，完成后立即结束，不会累计时长。比如SIT部署完成后，通过手动触发（workflow_dispatch）或环境审批触发UAT工作流；UAT验收完成后，再触发Prod工作流。

• 利用环境审批衔接阶段
  在仓库中配置UAT、Prod专属环境，给每个环境添加审批规则。工作流中部署到UAT环境后即结束，当UAT验收通过，由负责人通过环境审批触发后续的Prod部署步骤，确保每个工作流的实际运行时长都远低于35天。

• 通过事件触发跨阶段工作流
  使用repository_dispatch或workflow_call实现工作流间的触发。比如SIT工作流成功结束后，发送一个自定义事件触发UAT工作流；UAT阶段完成后（可通过手动标记状态或外部系统回调），再触发Prod工作流。这种方式能让每个阶段的工作流独立运行，避免长时间挂起。

• 避免工作流长期等待
  不要让工作流处于“等待UAT完成”的挂起状态，而是在部署完UAT后立即终止当前工作流。等UAT验收通过后，再通过手动触发、API调用或标签推送等方式启动Prod部署工作流，确保每个工作流的运行时长都在限制内。

内容的提问来源于stack exchange，提问作者ChzDz