GitHub Actions带needs/if条件的动态测试重跑任务实现咨询

要实现带依赖/条件控制的动态次数重跑，同时避免代码重复，可通过复合步骤封装逻辑+动态矩阵生成作业的方式解决，具体实现如下：

1. 封装重复逻辑为复合步骤 #

创建一个复合步骤，把重跑测试和结果分析的重复逻辑整合到一起，避免在工作流中多次编写相同代码。在仓库的.github/actions/rerun-test-suite/action.yml中添加以下内容：

name: 'Rerun Test Suite'
description: '执行失败测试重跑并分析结果'
inputs:
  failed-test-id:
    description: '失败测试的ID'
    required: true
  runner-tag:
    description: '自定义基础设施的Runner标签'
    required: true
outputs:
  test-id:
    description: '重跑测试的ID'
    value: ${{ steps.test.outputs.test-id }}
  result-failed:
    description: '结果分析是否失败'
    value: ${{ steps.parse-test-result.outcome == 'failure' }}
runs:
  using: 'composite'
  steps:
    - name: 重跑失败测试
      id: test
      uses: somedir/test@v1.0.0
      with:
        failed_test_id: ${{ inputs.failed-test-id }}
      shell: bash

    - name: 解析并分析重跑结果
      id: parse-test-result
      uses: somedir/test-analyze-results@v1.0.0
      with:
        test-id: ${{ steps.test.outputs.test-id }}
      shell: bash

2. 动态生成重跑矩阵 #

通过一个辅助作业生成包含重跑轮次、依赖关系、参数来源的动态矩阵，支持任意重跑次数：

name: 测试重跑工作流
on:
  workflow_dispatch:
    inputs:
      runner-tag:
        description: '自定义基础设施Runner标签'
        required: true
      rerun-count:
        description: '最大重跑次数'
        required: true
        default: '3'

jobs:
  # 初始测试作业（保留你现有配置）
  first-tests:
    runs-on: ${{ inputs.runner-tag }}
    outputs:
      test-id: ${{ steps.test.outputs.test-id }}
    steps:
      # ... 你的初始测试步骤，需输出test-id

  # 初始测试结果分析（保留你现有配置）
  first-tests-results:
    needs: first-tests
    runs-on: ${{ inputs.runner-tag }}
    outputs:
      result-failed: ${{ steps.parse-test-result.outcome == 'failure' }}
    steps:
      - name: 解析初始测试结果
        id: parse-test-result
        uses: somedir/test-analyze-results@v1.0.0
        with:
          test-id: ${{ needs.first-tests.outputs.test-id }}

  # 生成动态重跑矩阵
  generate-rerun-matrix:
    runs-on: ubuntu-latest
    outputs:
      matrix: ${{ steps.generate.outputs.matrix }}
    steps:
      - id: generate
        run: |
          RERUN_COUNT=${{ inputs.rerun-count }}
          # 生成包含每个重跑轮次信息的矩阵
          MATRIX=$(jq -n --argjson count "$RERUN_COUNT" '
            {
              reruns: [
                range(1; $count + 1) | {
                  index: .,
                  depends_on: (
                    if . == 1 then "first-tests-results"
                    else "rerun-test-suite-\(. - 1)"
                    end
                  ),
                  test_id_source: (
                    if . == 1 then "first-tests"
                    else "rerun-test-suite-\(. - 1)"
                    end
                  )
                }
              ]
            }
          ')
          echo "matrix=$MATRIX" >> $GITHUB_OUTPUT

  # 动态生成的重跑作业
  rerun-test-suite:
    needs: [generate-rerun-matrix, first-tests, first-tests-results]
    strategy:
      matrix:
        include: ${{ fromJSON(needs.generate-rerun-matrix.outputs.matrix).reruns }}
    name: 重跑测试套件 ${{ matrix.index }}
    runs-on: ${{ inputs.runner-tag }}
    outputs:
      test-id: ${{ steps.rerun-suite.outputs.test-id }}
      result-failed: ${{ steps.rerun-suite.outputs.result-failed }}
    # 动态设置依赖：第一次重跑依赖初始结果分析，后续依赖上一次重跑作业
    needs:
      - ${{ matrix.depends_on }}
      - ${{ matrix.test_id_source }}
    # 动态设置执行条件：仅当依赖作业结果失败且测试源作业成功时执行
    if: |
      ${{
        needs[matrix.depends_on].outputs.result-failed == 'true' &&
        needs[matrix.test_id_source].result == 'success'
      }}
    steps:
      - name: 执行重跑测试套件
        id: rerun-suite
        uses: ./.github/actions/rerun-test-suite
        with:
          failed-test-id: ${{ needs[matrix.test_id_source].outputs.test-id }}
          runner-tag: ${{ inputs.runner-tag }}

  # 最终分析步骤（所有重跑完成后执行）
  final-analysis:
    needs: [first-tests-results, rerun-test-suite]
    if: always()
    runs-on: ${{ inputs.runner-tag }}
    steps:
      - name: 汇总所有测试结果分析
        run: |
          echo "所有测试及重跑完成，开始最终分析"
        shell: bash

核心优势 #

• 无代码重复：通过复合步骤封装重跑和分析逻辑，工作流中仅需调用一次
• 动态重跑次数：通过rerun-count输入参数控制重跑次数，支持1到99次任意配置
• 依赖与条件自动控制：每个重跑作业自动继承上一次的依赖关系和执行条件，无需手动维护
• 符合工作流深度限制：所有作业均为平级依赖，不会触发嵌套工作流的深度限制

内容的提问来源于stack exchange，提问作者Sven van den Boogaart