GitHub Actions：如何避免工作流并发运行？

针对你遇到的main分支频繁推送导致部署工作流并发失败的问题，有几种直接的解决方案：

1. 让工作流排队等待，不并发执行 #

在你的工作流YAML文件开头添加concurrency配置，指定同一个分支的工作流归为一组，并且不取消正在运行的实例——这样新触发的工作流会自动排队，等前面的完成后再启动。

示例配置：

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: false

这里github.ref会自动识别当前分支（比如main），确保只有同分支的工作流会互相排队，不会影响其他分支的工作流。

2. 取消旧运行，只执行最新的部署 #

如果不想让旧的工作流占用资源排队，而是直接让最新的推送触发的工作流取代正在运行的旧实例，可以把cancel-in-progress设为true：

示例配置：

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

这种方式适合Renovate批量更新这类场景——短时间内多次合并PR时，旧的部署会被直接取消，只保留最新的一次部署运行，避免因版本变更导致的冲突。

3. 延迟启动，合并短时间内的多次推送 #

如果想让短时间内的多次推送只触发一次部署，可以在工作流开头加一段延迟，同时结合上面的并发取消配置：

示例配置：

concurrency:
  group: main-deployment
  cancel-in-progress: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 延迟1分钟，合并频繁推送
        run: sleep 60
      - name: 检出代码
        uses: actions/checkout@v4
      # 这里放你的部署步骤，比如构建、推送镜像、部署到服务器等

原理是：每次推送触发工作流后，先等1分钟，这段时间如果有新的推送触发了新的工作流，当前正在等待的旧工作流会被取消。最终只有最后一次推送对应的工作流会完成延迟，执行后续的部署操作，实现“多次推送只跑一次”的效果。

你可以根据自己的需求选择合适的方案：如果需要每个推送的部署都执行，选第一种排队方案；如果只关心最新版本的部署，选第二种取消旧运行的方案；如果想合并短时间内的多次推送，选第三种延迟+取消的组合。

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