通过 GitHub Actions 自动化 Dependabot

介绍如何使用 GitHub Actions 自动执行常见的与 Dependabot 相关的任务的示例。

谁可以使用此功能？

具有写入访问权限的用户

在本文中

注意

本文介绍如何使用 Dependabot 自动执行与 GitHub Actions 相关的任务。 有关使用 Dependabot updates 运行 GitHub Actions 的详细信息，请改为参阅 GitHub Actions 运行器上的 Dependabot。

当 GitHub Actions 创建用于更新依赖项的拉取请求时，您可以使用 Dependabot 执行自动化任务。 如果你想执行以下操作，可能会发现这很有用：

  • 确保 Dependabot 创建的拉取请求（版本更新和安全更新）包含适合您的工作流程的正确数据，包括标签和名称。

  • 触发工作流，将 Dependabot 拉取请求（版本更新和安全更新）纳入您的审核流程，或自动合并。

关于 Dependabot 和 GitHub Actions

重要

如果为仓库启用了 Dependabot，它将始终在 GitHub Actions 上运行，并绕过 Actions 策略检查以及仓库或组织级别的禁用设置。 这可确保在启用 Dependabot 时始终运行安全和版本更新工作流。

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

Dependabot 能够在其拉取请求和评论上触发 GitHub Actions 工作流程；但是，某些事件的处理方式不同。 有关详细信息，请参阅 对 GitHub Actions 上的 Dependabot 进行故障排除。

下面是几个可借助 GitHub Actions 实现自动化的拉取请求常见场景。

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

大多数自动化要求你了解拉取请求内容的信息：依赖项名称是什么，是否为生产依赖项，以及是否为主要、次要或补丁更新。 您可以使用某个操作来检索由 Dependabot 生成的拉取请求中正在更新的依赖项的信息。

Example:

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

permissions:
  pull-requests: write
  issues: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@d7267f607e9d3fb96fc2fbe83e0af444713e90b7
        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 标签的其他自动化或会审工作流，则可以配置操作以基于提供的元数据分配标签。

使用标签标记所有生产依赖项更新的示例：

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

permissions:
  pull-requests: write
  issues: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@d7267f607e9d3fb96fc2fbe83e0af444713e90b7
        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 拉取请求。

Example:

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

permissions:
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@d7267f607e9d3fb96fc2fbe83e0af444713e90b7
        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 的“自动合并”功能。 这样，如果分支保护规则所需的任何测试和批准都成功满足，拉取请求就可合并。

有关详细信息，请参阅 自动合并拉取请求 和 管理分支保护规则。

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

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

permissions:
  contents: write
  pull-requests: write

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: github.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/fetch-metadata@d7267f607e9d3fb96fc2fbe83e0af444713e90b7
        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}}

注意

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

如果目标分支使用合并队列，则内置 GITHUB_TOKEN 无法向队列添加拉取请求。 在这种情况下，必须使用具有合并权限的 personal access token 或 GitHub App 令牌对工作流进行身份验证，并在 GITHUB_TOKEN 步骤中使用该令牌替代 gh pr merge。

Dependabot 和 GitHub Actions 策略

通常，工作流是否可以在存储库中运行取决于 GitHub Actions策略检查 ，以及是在 GitHub Actions 组织级别还是存储库级别 启用 。 这些控件可以限制工作流的运行，尤其是在外部操作被阻止或 GitHub Actions 完全禁用时。

但是，当为某个存储库启用 Dependabot 时，其工作流将始终在 GitHub Actions 上运行，绕过 Actions 策略检查和禁用限制。

  • Dependabot 工作流不受操作禁用或企业策略限制阻止。
  • 即使禁止外部操作，这些工作流中引用的操作也仍允许运行。

有关详细信息，请参阅“GitHub Actions 运行器上的 Dependabot”。

调查失败的工作流运行

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

  • 只有当正确的角色触发工作流程时，才运行工作流程。
  • 你正在检查 ref 的正确 pull_request 值。
  • 您的机密信息以 Dependabot 机密的形式提供，而不是以 GitHub Actions 机密的形式提供。
  • 你有一个具有适当权限的 GITHUB_TOKEN。

有关编写和调试 GitHub Actions的信息，请参阅 撰写工作流程。

有关帮助解决工作流问题的更多提示，请参阅 对 GitHub Actions 上的 Dependabot 进行故障排除。