使用GitHub Environments时无法调用azure/login@v2的问题求助

当工作流的Job关联了GitHub Environment（即指定了environment: ${{ inputs.environment }}）后，该Job默认只能访问对应Environment下配置的Secrets，仓库级的Secrets不会自动被加载。你当前将AZURE_CREDENTIALS存在仓库级Secrets中，但dev/test/prod这几个Environment并没有配置同名的Secret，所以在可重用工作流的Azure Login步骤中，${{ secrets.AZURE_CREDENTIALS }}实际为空，导致登录时缺少client-id和tenant-id，触发错误。

以下两种方案任选其一：

方案1：将凭证复制到各Environment的Secrets中 #

这是符合Environment权限隔离的标准做法（适用于不同环境需要不同Azure服务主体的场景）：

• 进入GitHub仓库的「Settings」→「Environments」
• 依次打开dev、test、prod环境的设置页面
• 在「Secrets」区域点击「Add secret」，创建名为AZURE_CREDENTIALS的Secret，内容与仓库级的凭证完全一致

方案2：调用可重用工作流时显式传递仓库级Secret #

如果你的场景允许所有环境共享同一个Azure服务主体，可以通过传递Secrets的方式让可重用工作流访问仓库级Secret：

1. 修改触发工作流的call_az_terra Job，添加secrets参数传递凭证：

call_az_terra:
  needs: parse_and_call
  uses: ./.github/workflows/az_terra.yml
  with:
    environment: ${{ needs.parse_and_call.outputs.environment }}
  secrets:
    AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

2. 修改可重用工作流的定义，添加接收Secret的配置：

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    secrets:
      AZURE_CREDENTIALS:
        required: true

3. 保持可重用工作流中Azure Login步骤的配置不变即可。

可以在可重用工作流中添加一个debug步骤，确认Secret是否被正确加载（避免泄露敏感信息，只输出长度）：

- name: Check Secret availability
  run: echo "Secret content length: ${#AZURE_CREDENTIALS}"
  env:
    AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

如果输出长度大于0，说明Secret已正确加载。

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