对 GitHub Actions 上的 Dependabot 进行故障排除

排查 Dependabot 触发现有工作流时的失败问题

为 Dependabot 设置你的 GitHub Enterprise Server 实例更新后，当现有工作流由 Dependabot 事件触发时，可能会出现失败情况。

默认情况下，由 GitHub Actions 从 push、pull_request、pull_request_review 或 pull_request_review_comment 事件触发的 Dependabot 工作流运行会被视为如同它们是从仓库派生打开的一样。与由其他操作主体触发的工作流不同，这意味着这类工作流会收到一个只读的 GITHUB_TOKEN，并且无法访问任何通常可用的机密信息。这将导致尝试写入存储库的任何工作流在触发 Dependabot时失败。

有三种方法可以解决此问题：

你可以更新你的工作流，使其不再由 Dependabot 触发，可使用如下表达式：if: github.actor != 'dependabot[bot]'。有关详细信息，请参阅“对工作流和操作中的表达式求值”。
可以修改工作流以使用包含 pull_request_target 的两步过程，该过程没有这些限制。有关详细信息，请参阅“对 GitHub Actions 上的 Dependabot 进行故障排除”。
您可以提供由 Dependabot 对密钥的访问触发的工作流，并允许使用 permissions 这一术语来扩大 GITHUB_TOKEN 的默认作用域。

本文提供了一些故障排除建议。你还可以参阅 GitHub Actions 的工作流语法。

访问密钥

Dependabot当事件触发工作流时，工作流唯一可用的机密是Dependabot机密。 GitHub Actions 机密 不可用。因此，您必须将由 Dependabot 事件触发的工作流所使用的任何机密存储为 Dependabot 机密。有关详细信息，请参阅“为 Dependabot 配置对专用注册表的访问权限”。

Dependabot 密钥会被添加到 secrets 上下文中，并使用与 GitHub Actions 的密钥完全相同的语法进行引用。有关详细信息，请参阅“在 GitHub Actions 中使用机密”。

如果你有一个工作流，既会由 Dependabot 触发，也会由其他参与方触发，最简单的解决方案是将具有所需权限的令牌存储在 action 和 Dependabot 机密中，并使二者的名称相同。然后，工作流程可以包括对这些机密的单个调用。如果 Dependabot 的密钥名称不同，请使用条件为不同的参与方指定其应使用的正确密钥。

有关使用条件的示例，请参阅通过 GitHub Actions 自动化 Dependabot。

要使用用户名和密码访问 AWS 上的私有容器注册表，工作流必须包含 username 和 password 的机密。

在此示例中，当 Dependabot 触发工作流时，将使用名称分别为 READONLY_AWS_ACCESS_KEY_ID 和 READONLY_AWS_ACCESS_KEY 的 Dependabot 机密。如果另一个执行组件触发了工作流程，则使用具有这些名称的操作机密。

YAML

# 此工作流使用未经 GitHub 认证的操作。
# 它们由第三方提供，并受
# 单独的服务条款、隐私政策和支持
# 文档。
name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

# 此工作流使用未经 GitHub 认证的操作。
# 它们由第三方提供，并受
# 单独的服务条款、隐私政策和支持
# 文档。
name: CI
on:
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6

      - name: Login to private container registry for dependencies
        uses: docker/login-action@3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c
        with:
          registry: https://1234567890.dkr.ecr.us-east-1.amazonaws.com
          username: ${{ secrets.READONLY_AWS_ACCESS_KEY_ID }}
          password: ${{ secrets.READONLY_AWS_ACCESS_KEY }}

      - name: Build the Docker image
        run: docker build . --file Dockerfile --tag my-image-name:$(date +%s)

更改 `GITHUB_TOKEN` 权限

默认情况下，由 GitHub Actions 触发的 Dependabot 工作流会获得一个具有只读权限的 GITHUB_TOKEN。可以使用工作流中的 permissions 密钥来增加对令牌的访问权限：

YAML

name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  ...

jobs:
  ...

name: CI
on: pull_request

# Set the access for individual scopes, or use permissions: write-all
permissions:
  pull-requests: write
  issues: write
  ...

jobs:
  ...

有关详细信息，请参阅“在工作流中使用 GITHUB_TOKEN 进行身份验证”。

手动重新运行工作流程

手动重新运行 Dependabot 工作流时，即使启动重新运行的用户具有不同的权限，也会使用与之前相同的权限运行。有关详细信息，请参阅“重新运行工作流程和作业”。

在本文中

排查 Dependabot 触发现有工作流时的失败问题

访问密钥

更改 GITHUB_TOKEN 权限

手动重新运行工作流程

更改 `GITHUB_TOKEN` 权限