GitHub Actions工作流默认排序规则及FIFO执行配置方法

在GitLab中，同一流水线的多个实例可能同时执行，其作业在满足要求后立即运行。要禁用此行为，可将GitLab配置为使用process_mode=oldest-first：

curl --request PUT --data "process_mode=oldest_first" \
--header "PRIVATE-TOKEN: $TOKEN" "https://example.com/api/v4/projects/3465/resource_groups/deploy-release"

针对你提出的GitHub Actions相关问题，解答如下：

1. 同一时间可执行多少个工作流？ #

• 并发数取决于你的账户类型：
  • 公共仓库：免费版用户默认最多同时跑20个工作流作业，私有仓库最多10个
  • GitHub Team/Enterprise用户：私有仓库最多同时跑50个工作流作业
  • 这些上限可在GitHub后台调整，但平台有全局限制，超出的工作流会自动进入排队队列

2. 不同工作流执行之间的作业如何排序？ #

• 默认按触发时间先到先服务，早触发的工作流优先进入执行队列
• 用concurrency限制并发时，排队的工作流默认是最新优先——新触发的会排前面，甚至能替换旧的排队任务；但可以通过配置调整这个逻辑
• 同一工作流内的作业按needs定义的依赖顺序执行；跨工作流的作业则跟着各自工作流的排队优先级走

3. 如何配置工作流执行？ #

结合你给出的场景（含test、build、deploy作业，deploy调用复用工作流，已配置needs和concurrency:1，需确保首个工作流的deploy优先运行），具体配置方式如下：

核心配置要点 #

• 保留needs依赖：确保test完成后跑build，build完成后跑deploy，维持作业的依赖顺序
• 调整concurrency策略：默认的concurrency是最新优先，要实现旧工作流优先，需做以下设置：
  1. 给concurrency.group设唯一标识（比如按分支或项目分组）
  2. 开启concurrency.cancel-in-progress: false，避免正在运行的deploy被新工作流中断
  3. 利用队列的先到先服务特性：GitHub Actions没有直接的"oldest-first"配置，但通过不取消旧任务+队列默认规则，就能实现最早触发的deploy优先执行
• 复用工作流的concurrency继承：被调用的复用工作流会继承调用方的concurrency配置，若复用工作流自己有配置则会覆盖调用方的

示例配置片段 #

name: CI/CD Pipeline
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: echo "Running tests..."

  build:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: Build artifact
        run: echo "Building artifact..."

  deploy:
    needs: build
    runs-on: ubuntu-latest
    concurrency:
      group: deploy-group-${{ github.ref }} # 按分支分组，保证同一分支的deploy串行
      cancel-in-progress: false # 不中断正在运行的deploy任务
    steps:
      - name: Call reusable deploy workflow
        uses: ./.github/workflows/reusable-deploy.yml

补充说明 #

• 如果需要跨分支的deploy都串行，把concurrency.group设为固定值即可（比如global-deploy-group）
• 多个工作流触发后，因为cancel-in-progress: false，新的deploy会进入排队，而队列默认先到先服务，最早触发的工作流的deploy会优先执行

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