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_TOKENhas 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
После настройки обновлений Dependabot для ваш экземпляр GitHub Enterprise Serverмогут возникнуть сбои при активации существующих рабочих процессов событиями Dependabot .
По умолчанию запуски рабочих процессов GitHub Actions, которые активируются Dependabot при наступлении событий push, pull_request, pull_request_review или pull_request_review_comment, обрабатываются так, как если бы они были открыты из вилки репозитория. Это означает, что в отличие от рабочих процессов, активированных другими субъектами, они получают GITHUB_TOKEN только для чтения и не имеют доступа к секретам, которые обычно доступны. Это приводит к сбою любых рабочих процессов, которые пытаются выполнить запись в репозиторий при активации из Dependabot.
Существует три способа решения этой проблемы.
- Вы можете изменить рабочие процессы так, чтобы они больше не активировались из Dependabot, с помощью следующего выражения:
if: github.actor != 'dependabot[bot]'. Дополнительные сведения см. в разделе Оценка выражений в рабочих процессах и действиях. - Вы можете изменить рабочие процессы так, чтобы использовался двухэтапный процесс с событием
pull_request_target, которое не имеет таких ограничений. Дополнительные сведения см. в разделе Автоматизация Dependabot с помощью GitHub Actions. - Вы можете предоставить рабочим процессам, активируемым из Dependabot, доступ к секретам и разрешить термину
permissionsувеличивать областьGITHUB_TOKENпо умолчанию.
Some troubleshooting advice is provided in this article. You can also see Синтаксис рабочего процесса для 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 Настройка доступа к частным реестрам для 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 Использование секретов в GitHub Actions.
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 Автоматизация Dependabot с помощью 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 Автоматическая проверка подлинности токенов.
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 Повторный запуск рабочих процессов и заданий.