Skip to main content

通过 GitHub Actions 自动化 Dependabot

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

谁可以使用此功能?

People with write permissions to a repository can configure GitHub Actions to respond to Dependabot-created pull requests.

关于 Dependabot 与 GitHub Actions

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

响应事件

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

对于 Dependabot (github.actor == 'dependabot[bot]') 使用 pull_requestpull_request_reviewpull_request_review_commentpushcreatedeploymentdeployment_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 上的私有容器注册表,工作流必须包含 usernamepassword 的机密。 在下面的示例中,当 Dependabot 触发工作流时,将使用名称为 READONLY_AWS_ACCESS_KEY_IDREADONLY_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@v1
        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@v1
        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@v1
        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@v1
        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”。