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

本文提供有关在使用DependabotGitHub Actions时可能会遇到的问题的故障排除信息。

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

为 Dependabot 设置 GitHub.com 更新后，当现有工作流由 Dependabot 事件触发时，你可能会看到失败。

默认情况下，由 GitHub Actions 从 `push`、`pull_request`、`pull_request_review` 或 `pull_request_review_comment` 事件中触发的 Dependabot 工作流运行被视为从存储库分支中打开。 与其他参与者触发的工作流不同，这意味着它们会接收一个只读 `GITHUB_TOKEN`，并且无权访问任何通常可用的机密。 这将导致尝试写入仓库的任何工作流程在由 Dependabot 触发时失败。

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

1. 可以更新工作流，使其不再由 Dependabot 使用如下表达式触发：`if: github.actor != 'dependabot[bot]'`。 有关详细信息，请参阅“[对工作流和操作中的表达式求值](/zh/actions/learn-github-actions/expressions)”。
2. 可以修改工作流以使用包含 `pull_request_target` 的两步过程，该过程没有这些限制。 有关详细信息，请参阅“[对 GitHub Actions 上的 Dependabot 进行故障排除](/zh/code-security/dependabot/troubleshooting-dependabot/troubleshooting-dependabot-on-github-actions#restrictions-when-dependabot-triggers-events)”。
3. 可为由 Dependabot 触发的工作流提供对机密的访问权限，并允许 `permissions` 术语增加 `GITHUB_TOKEN` 的默认范围。

本文提供了一些故障排除建议。 你还可以参阅 [GitHub Actions 的工作流语法](/zh/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions)。

### 访问密钥

Dependabot当事件触发工作流时，工作流唯一可用的机密是Dependabot机密。
GitHub Actions 机密 **不可用**。 因此，您必须将由 Dependabot 事件触发的工作流所使用的任何机密存储为 Dependabot 机密。 有关详细信息，请参阅“[为 Dependabot 配置对专用注册表的访问权限](/zh/code-security/dependabot/working-with-dependabot/configuring-access-to-private-registries-for-dependabot#storing-credentials-for-dependabot-to-use)”。

Dependabot 密钥会被添加到 `secrets` 上下文中，并使用与 GitHub Actions 的密钥完全相同的语法进行引用。 有关详细信息，请参阅“[在 GitHub Actions 中使用机密](/zh/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow)”。

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

有关使用条件的示例，请参阅 [通过 GitHub Actions 自动化 Dependabot](/zh/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions)。

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

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

```yaml copy
# 此工作流使用未经 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 copy
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 进行身份验证](/zh/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)”。

## 手动重新运行工作流程

手动重新运行 Dependabot 工作流时，即使启动重新运行的用户具有不同的权限，也会使用与之前相同的权限运行。 有关详细信息，请参阅“[重新运行工作流程和作业](/zh/actions/managing-workflow-runs/re-running-workflows-and-jobs)”。