如何配置GitHub Actions:同类型Runner测试串行,不同类型并行
解决方案
要实现同类型Runner上测试串行、不同类型Runner间并行的需求,核心是利用concurrency按Runner类型分组,并关闭任务取消机制,让同组任务排队执行而非中断正在运行的任务。具体配置如下:
完整工作流示例
name: Test Workflow on: [push] jobs: run-tests: runs-on: ${{ matrix.runner }} strategy: matrix: runner: [t4g.small, t4g.medium, t4g.large] test: [test1, test2, test3] concurrency: # 按Runner类型分组,确保同类型Runner的任务排队 group: test-group-${{ matrix.runner }} # 关键:关闭正在执行任务的取消,改为排队等待 cancel-in-progress: false steps: - name: Checkout code uses: actions/checkout@v4 - name: Run ${{ matrix.test }} on ${{ matrix.runner }} run: | # 替换为你的实际测试命令,比如npm run ${{ matrix.test }} echo "Running test ${{ matrix.test }} on runner ${{ matrix.runner }}" sleep 30 # 模拟测试耗时
配置说明
- 矩阵策略:保留
runner和test的组合矩阵,生成所有测试与Runner类型的任务组合。 - concurrency分组:通过
group: test-group-${{ matrix.runner }}将同一Runner类型的所有测试任务归为一组,GitHub Actions会自动让同组任务按提交顺序排队执行。 - cancel-in-progress: false:这是解决你之前任务被取消问题的核心——默认该值为
true,会中断同组正在运行的任务,改为false后,新任务会等待当前任务完成再启动,完全符合串行需求。 - 并行逻辑:不同Runner类型的任务属于不同的
concurrency组,因此会同时并行执行,不会互相阻塞。
替代方案(无concurrency依赖)
如果完全不想依赖concurrency机制,可以将每个Runner类型作为独立Job,在Job内部通过步骤串行执行所有测试:
name: Test Workflow on: [push] jobs: test-on-small: runs-on: t4g.small steps: - uses: actions/checkout@v4 - name: Run test1 run: echo "Running test1 on t4g.small" && sleep 30 - name: Run test2 run: echo "Running test2 on t4g.small" && sleep 30 - name: Run test3 run: echo "Running test3 on t4g.small" && sleep 30 test-on-medium: runs-on: t4g.medium steps: - uses: actions/checkout@v4 - name: Run test1 run: echo "Running test1 on t4g.medium" && sleep 30 - name: Run test2 run: echo "Running test2 on t4g.medium" && sleep 30 - name: Run test3 run: echo "Running test3 on t4g.medium" && sleep 30 test-on-large: runs-on: t4g.large steps: - uses: actions/checkout@v4 - name: Run test1 run: echo "Running test1 on t4g.large" && sleep 30 - name: Run test2 run: echo "Running test2 on t4g.large" && sleep 30 - name: Run test3 run: echo "Running test3 on t4g.large" && sleep 30
这种方式下,每个Runner类型对应一个独立Job,Job内部的测试步骤天然串行,不同Job之间自动并行。缺点是测试用例较多时,配置会显得冗余,不如矩阵+concurrency的方式简洁。
内容的提问来源于stack exchange,提问作者Mohit Kumar
相关产品推荐
相关产品推荐

