关于 Dependabot 和 GitHub Actions
Dependabot 创建拉取请求以使您的依赖项保持最新,您可以使用 GitHub Actions 在创建这些拉取请求时执行自动任务。例如,获取其他工件、添加标签、运行测试或以其他方式修改拉取请求。
注意
本文档介绍了如何使用 GitHub Actions 自动化 Dependabot 相关任务。有关在 GitHub Actions 上运行 Dependabot 更新的更多信息,请参阅“关于 GitHub Actions 运行器上的 Dependabot”代替。
响应事件
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
事件启动的工作流,如果拉取请求的基本 ref 由 Dependabot (github.event.pull_request.user.login == '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@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)
手动重新运行工作流
手动重新运行 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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
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.event.pull_request.user.login == 'dependabot[bot]' && github.repository == 'owner/my_repo'
steps:
- name: Dependabot metadata
id: metadata
uses: dependabot/fetch-metadata@4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d
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 的信息,请参阅“编写工作流”。