如何让GitHub Actions必填工作流依赖另一工作流？

我配置了两个GitHub Actions必填工作流，作为PR的检查环节：

1. Terraform PR Plans：执行Terraform Plan并将计划上传至Azure存储账户，由pull_request触发。
2. Code Scan - Non Prod：需要下载上述Terraform Plan并执行OPA合规扫描，同样是必填工作流，只能通过pull_request触发。

现在需要确保Terraform Plan工作流完成后，再启动OPA扫描的必填工作流。尝试过workflow_run和repository_dispatch触发器，但由于必填工作流仅支持PR触发器，这些方法不适用。

解决方案1：合并工作流，使用作业依赖 #

将两个任务整合到同一个PR触发的工作流中，通过needs关键字让OPA扫描作业依赖Terraform Plan作业，确保只有Plan完成且成功后才会执行扫描。

示例代码：

name: PR Checks (Terraform + OPA Scan)

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
    id-token: write
    contents: read
    pull-requests: write
    repository-projects: write

jobs:
  terraform-plan:
    name: Terraform Plan & Upload to Azure
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # 添加Terraform初始化、Plan生成、上传到Azure的步骤
      - name: Initialize Terraform
        run: terraform init
      - name: Generate Terraform Plan
        run: terraform plan -out=tfplan
      - name: Upload Plan to Azure Storage
        run: |
          # 替换为你的Azure存储上传命令，例如：
          # az storage blob upload --account-name <your-account> --container-name <your-container> --file tfplan --name tfplan-${{ github.sha }}

  opa-scan:
    name: OPA Compliance Scan
    runs-on: ubuntu-latest
    needs: terraform-plan  # 依赖terraform-plan作业，仅当该作业成功时才运行
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Download Terraform Plan from Azure
        run: |
          # 替换为你的Azure存储下载命令，例如：
          # az storage blob download --account-name <your-account> --container-name <your-container> --name tfplan-${{ github.sha }} --file tfplan
      - name: Run OPA Scan
        run: |
          # 替换为你的OPA扫描命令，例如：
          # opa eval -i tfplan -d policies/ "data.terraform.plan.resource_changes"

解决方案2：在扫描工作流中添加前置检查 #

如果必须保持两个独立的工作流，可以在OPA扫描工作流中添加一个前置作业，通过GitHub API检查Terraform Plan工作流的运行状态，等待其完成并确认成功后再执行扫描。

示例代码：

name: Code Scan - Non Prod

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
    id-token: write
    contents: read
    pull-requests: write
    repository-projects: write
    checks: read  # 需添加该权限以读取工作流运行状态

jobs:
  wait-for-terraform-plan:
    name: Wait for Terraform Plan Completion
    runs-on: ubuntu-latest
    steps:
      - name: Check and Wait for Terraform Plan Workflow
        run: |
          PR_SHA="${{ github.event.pull_request.head.sha }}"
          REPO="${{ github.repository }}"
          WORKFLOW_NAME="Terraform PR Plans"
          GITHUB_TOKEN="${{ secrets.GITHUB_TOKEN }}"

          # 循环检查工作流状态直到完成
          while true; do
            # 调用GitHub API获取最新的对应工作流运行信息
            WORKFLOW_DATA=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
              "https://api.github.com/repos/$REPO/actions/runs?event=pull_request&head_sha=$PR_SHA&workflow_name=$WORKFLOW_NAME")
            
            WORKFLOW_STATUS=$(echo "$WORKFLOW_DATA" | jq -r '.workflow_runs[0].status')
            WORKFLOW_CONCLUSION=$(echo "$WORKFLOW_DATA" | jq -r '.workflow_runs[0].conclusion')

            if [ "$WORKFLOW_STATUS" = "completed" ]; then
              if [ "$WORKFLOW_CONCLUSION" != "success" ]; then
                echo "Terraform Plan workflow failed with conclusion: $WORKFLOW_CONCLUSION"
                exit 1
              fi
              echo "Terraform Plan workflow completed successfully"
              break
            fi

            echo "Terraform Plan workflow is still running (status: $WORKFLOW_STATUS), waiting 30 seconds..."
            sleep 30
          done

  opa-scan:
    name: Execute OPA Scan
    runs-on: ubuntu-latest
    needs: wait-for-terraform-plan
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Download Terraform Plan from Azure
        run: |
          # 替换为你的Azure下载命令
      - name: Run OPA Compliance Scan
        run: |
          # 替换为你的OPA扫描命令

关键说明 #

• GitHub 必填工作流的限制：确实仅支持pull_request或pull_request_target触发器，因此workflow_run或repository_dispatch触发的工作流无法设置为必填，这是你之前尝试失败的核心原因。
• 方案1的优势：结构更简洁，依赖关系明确，无需额外API调用，适合可以合并工作流的场景。
• 方案2的优势：保留两个独立工作流，适合已有工作流结构无法调整的场景，需注意GitHub API的调用频率限制，以及确保已配置足够的权限。

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