如何在GitHub Actions中实现多个工作流运行排队（无需外部机制）

是的，完全可以通过调整GitHub Actions内置的concurrency配置实现多个工作流排队执行，不需要依赖外部队列机制。

默认行为导致的问题 #

你遇到的「新工作流提交后旧等待任务被取消」是concurrency的默认行为：同一并发组中，当新任务进入队列时，已在等待的旧任务会被自动取消，只保留最新的等待任务，正在运行的任务不受影响。这就是你看到Canceling since a higher priority waiting request for 'your-project' exists提示的原因。

修改配置实现排队 #

通过配置concurrency的两个参数就能改变这个行为，让所有工作流按提交顺序排队：

concurrency:
  group: your-project-group # 替换为你的并发组名称，比如按分支、项目名定义
  cancel-in-progress: false # 不终止正在运行的工作流
  cancel-waiting: false # 不取消已在队列中的等待任务

参数说明：

• cancel-in-progress: false：当并发组已有运行中的工作流时，新提交的工作流会进入等待队列，而非强行终止正在运行的任务。
• cancel-waiting: false：禁止后续提交的工作流取消队列中已存在的等待任务，确保所有提交的工作流都能按顺序等待执行。

示例场景 #

比如针对特定分支的部署工作流，你可以这样配置：

concurrency:
  group: ${{ github.ref }}-deploy # 每个分支单独一个并发组
  cancel-in-progress: false
  cancel-waiting: false

这样同一分支的所有部署工作流会依次排队，不会出现新提交挤掉旧等待任务的情况。

注意事项 #

这种内置排队方案完全依赖GitHub的并发控制能力，无需额外工具。但要注意GitHub对工作流队列的限制（比如免费仓库的队列长度、等待时长上限），如果是超大规模的任务排队场景，可能需要结合其他方案，但常规开发场景下足够满足需求。

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