Note
站点管理员必须先为 你的 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.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 的自动合并功能。 这样,如果分支保护规则所需的任何测试和批准都成功满足,拉取请求就可合并。 有关详细信息,请参阅 自动合并拉取请求 和 管理分支保护规则。
可以创建规则集作为分支保护规则的替代方法。 有关详细信息,请参阅 关于规则集。
Note
如果使用状态检查来测试拉取请求,则应为 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 的详细信息,请参阅 写入工作流。