通过 GitHub Actions 自动化 Dependabot

注意：站点管理员必须先为你的 GitHub Enterprise Server 实例设置 Dependabot updates，然后你才能使用此功能。有关详细信息，请参阅“为企业启用 Dependabot”。

如果企业所有者在企业级别设置了策略，则你可能无法启用或禁用 Dependabot updates。有关详细信息，请参阅“强制实施企业的代码安全性和分析策略”。

关于 Dependabot 与 GitHub Actions

Dependabot 创建拉动请求以保持依赖项的最新状态，并且当创建这些拉取请求时，您可以使用 GitHub Actions 执行自动任务。例如，获取其他构件、添加标签、运行测试或修改拉取请求。

响应事件

Dependabot 能够在其拉取请求和评论上触发 GitHub Actions 工作流程；但是，某些事件的处理方式不同。

对于 Dependabot (github.actor == 'dependabot[bot]') 使用 pull_request、pull_request_review、pull_request_review_comment、push、create、deployment 和 deployment_status 事件发起的工作流，具有以下限制：

GITHUB_TOKEN 默认拥有只读权限。
机密是从 Dependabot 机密填充的。 GitHub Actions 机密不可用。

对于 Dependabot (github.actor == 'dependabot[bot]') 使用 pull_request_target 事件发起的工作流，如果拉取请求的基本引用是由 Dependabot (github.actor == 'dependabot[bot]') 创建的，GITHUB_TOKEN 将是只读的，并且机密不可用。

即使工作流由其他参与者重新运行，这些限制也适用。

有关详细信息，请参阅“确保 GitHub Actions 和工作流安全：阻止 pwn 请求”。

更改 `GITHUB_TOKEN` 权限

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

name: CI
on: pull_request

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

jobs:
  ...

有关详细信息，请参阅“自动令牌身份验证”。

访问密钥

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

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

如果您的工作流程将由 Dependabot 和其他参与者触发，则最简单的解决方案是将令牌与操作以及名称相同的 Dependabot 密钥中所需的权限一起存储。然后，工作流程可以包括对这些机密的单个调用。如果 Dependabot 的机密具有不同的名称，请使用条件指定正确的机密，以供不同的参与者使用。有关使用条件的示例，请参阅下面的“常见自动化”。

要使用用户名和密码访问 AWS 上的私有容器注册表，工作流必须包含 username 和 password 的机密。在下面的示例中，当 Dependabot 触发工作流时，将使用名称为 READONLY_AWS_ACCESS_KEY_ID 和 READONLY_AWS_ACCESS_KEY 的 Dependabot 机密。如果另一个执行组件触发了工作流程，则使用具有这些名称的操作机密。

name: CI
on:
  pull_request:
    branches: [ main ]

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

      - name: Login to private container registry for dependencies
        uses: docker/login-action@v2
        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)

手动重新运行工作流程

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

常用 Dependabot 自动化

以下是可以使用 GitHub Actions 自动化的几个常见场景。

获取有关拉取请求的元数据

大量自动化需要了解拉取请求内容的信息：依赖项名称是什么，是否为生产依赖项，以及是否为主要、次要或补丁更新。

dependabot/fetch-metadata 操作为你提供了所有这些信息：

name: Dependabot fetch metadata
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      # The following properties are now available:
      #  - steps.metadata.outputs.dependency-names
      #  - steps.metadata.outputs.dependency-type
      #  - steps.metadata.outputs.update-type

有关详细信息，请参阅 dependabot/fetch-metadata 存储库。

标记拉取请求

如果您有基于 GitHub 标签的其他自动化或分类工作流程，则可以配置操作以根据提供的元数据分配标签。

例如，如果您想用标签标记所有生产依赖项更新：

name: Dependabot auto-label
on: pull_request

permissions:
  pull-requests: write
  issues: write
  repository-projects: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Add a label for all production dependencies
        if: steps.metadata.outputs.dependency-type == 'direct:production'
        run: gh pr edit "$PR_URL" --add-label "production"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}

批准拉取请求

如果您想要自动批准 Dependabot 拉取请求，您可以在工作流程中使用 GitHub CLI：

name: Dependabot auto-approve
on: pull_request

permissions:
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Approve a PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

在拉取请求上启用自动合并

如果要允许维护者标记某些拉取请求以进行自动合并，可以使用 GitHub 的自动合并功能。这样，如果分支保护规则所需的任何测试和批准都成功满足，拉取请求就可合并。有关详细信息，请参阅“自动合并拉取请求”和“管理分支保护规则”。

注意：如果使用状态检查来测试拉取请求，则应为 Dependabot 拉取请求的目标分支启用“合并前需要通过状态检查” 。此分支保护规则可确保除非所有必需的状态检查都通过，否则不合并拉取请求。有关详细信息，请参阅“管理分支保护规则”。

可以改为使用 GitHub Actions 和 GitHub CLI。以下示例会将所有补丁更新自动合并为 my-dependency：

name: Dependabot auto-merge
on: pull_request

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@v2
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"
      - name: Enable auto-merge for Dependabot PRs
        if: contains(steps.metadata.outputs.dependency-names, 'my-dependency') && steps.metadata.outputs.update-type == 'version-update:semver-patch'
        run: gh pr merge --auto --merge "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GH_TOKEN: ${{secrets.GITHUB_TOKEN}}

失败的工作流程运行故障排除

如果您的工作流程运行失败，请检查以下情况：

只有当正确的角色触发工作流程时，才运行工作流程。
你正在检查 pull_request 的正确 ref 值。
您的机密在 Dependabot 机密中可用，而不是作为 GitHub Actions 机密。
你有一个具有适当权限的 GITHUB_TOKEN。

有关编写和调试 GitHub Actions 的详细信息，请参阅“了解 GitHub Actions”。