Restrictions when Dependabot triggers events
Dependabot is able to trigger GitHub Actions workflows on its pull requests and comments; however, certain events are treated differently.
For workflows initiated by Dependabot (github.actor == 'dependabot[bot]'
) using the pull_request
, pull_request_review
, pull_request_review_comment
, push
, create
, deployment
, and deployment_status
events, these restrictions apply:
GITHUB_TOKEN
has read-only permissions by default.- Secrets are populated from Dependabot secrets. GitHub Actions secrets are not available.
For workflows initiated by Dependabot (github.actor == 'dependabot[bot]'
) using the pull_request_target
event, if the base ref of the pull request was created by Dependabot (github.event.pull_request.user.login == 'dependabot[bot]'
), the GITHUB_TOKEN
will be read-only and secrets are not available.
These restrictions apply even if the workflow is re-run by a different actor.
For more information, see Keeping your GitHub Actions and workflows secure: Preventing pwn requests.
Troubleshooting failures when Dependabot triggers existing workflows
Nachdem du Dependabot für GitHub.com eingerichtet hast, können Fehler angezeigt werden, wenn bestehende Workflows durch Dependabot-Ereignisse ausgelöst werden.
Standardmäßig werden Ausführungen von GitHub Actions-Workflows, die von Dependabot aufgrund von push
-, pull_request
-, pull_request_review
- oder pull_request_review_comment
-Ereignissen ausgelöst wurden, so behandelt, als wären sie in einem Repositoryfork geöffnet worden. Im Gegensatz zu Workflows, die von anderen Akteuren ausgelöst werden, erhalten sie ein schreibgeschütztes GitHub-Token (GITHUB_TOKEN
) und verfügen nicht über Zugriff auf Geheimnisse, die normalerweise verfügbar sind. Dies führt dazu, dass alle Workflows, die versuchen, in das Repository zu schreiben, fehlschlagen, wenn sie von Dependabot ausgelöst wurden.
Es gibt drei Möglichkeiten, dieses Problem zu beheben:
- Du kannst deine Workflows mit einem Ausdruck wie
if: github.actor != 'dependabot[bot]'
so aktualisieren, dass sie nicht mehr durch Dependabot ausgelöst werden. Weitere Informationen findest du unter Auswerten von Ausdrücken in Workflows und Aktionen. - Du kannst deine Workflows so ändern, dass sie einen zweistufigen Prozess mit
pull_request_target
verwenden, das nicht diesen Einschränkungen unterliegt. Weitere Informationen findest du unter Automatisieren von Dependabot mit GitHub Actions. - Du kannst Workflows bereitstellen, die durch den Dependabot-Zugriff auf Geheimnisse ausgelöst werden, und es dem Term
permissions
erlauben, den Standardbereich vonGITHUB_TOKEN
zu erhöhen.
Some troubleshooting advice is provided in this article. You can also see Workflowsyntax für GitHub Actions.
Accessing secrets
When a Dependabot event triggers a workflow, the only secrets available to the workflow are Dependabot secrets. GitHub Actions secrets are not available. You must therefore store any secrets that are used by a workflow triggered by Dependabot events as Dependabot secrets. For more information, see Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.
Dependabot secrets are added to the secrets
context and referenced using exactly the same syntax as secrets for GitHub Actions. For more information, see Verwenden von Geheimnissen in GitHub-Aktionen.
If you have a workflow that will be triggered by Dependabot and also by other actors, the simplest solution is to store the token with the permissions required in an action and in a Dependabot secret with identical names. Then the workflow can include a single call to these secrets. If the secret for Dependabot has a different name, use conditions to specify the correct secrets for different actors to use.
For examples that use conditions, see Automatisieren von Dependabot mit GitHub Actions.
To access a private container registry on AWS with a user name and password, a workflow must include a secret for username
and password
.
In this example, when Dependabot triggers the workflow, the Dependabot secrets with the names READONLY_AWS_ACCESS_KEY_ID
and READONLY_AWS_ACCESS_KEY
are used. If another actor triggers the workflow, the actions secrets with those names are used.
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)
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)
Changing GITHUB_TOKEN
permissions
By default, GitHub Actions workflows triggered by Dependabot get a GITHUB_TOKEN
with read-only permissions. You can use the permissions
key in your workflow to increase the access for the token:
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: ...
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:
...
For more information, see Automatische Tokenauthentifizierung.
Manually re-running a workflow
When you manually re-run a Dependabot workflow, it will run with the same privileges as before even if the user who initiated the rerun has different privileges. For more information, see Erneutes Ausführen von Workflows und Jobs.