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
Depois de configurar as atualizações do Dependabot para GitHub.com, você poderá ver as falhas quando os fluxos de trabalho existentes forem disparados por eventos do Dependabot.
Por padrão, as execuções de fluxo de trabalho do GitHub Actions disparadas pelo Dependabot dos eventos push, pull_request, pull_request_review ou pull_request_review_comment são tratados como se eles fossem abertos de um fork do repositório. Ao contrário dos fluxos de trabalho disparados por outros atores, isso significa que eles recebem o GITHUB_TOKEN somente leitura e não têm acesso a nenhum segredo que esteja normalmente disponível. Isso fará com que quaisquer fluxos de trabalho que tentam gravar no repositório falhem quando forem acionados por Dependabot.
Há três maneiras de resolver este problema:
- Você pode atualizar seus fluxos de trabalho para que não sejam mais disparados pelo Dependabot usando uma expressão como:
if: github.actor != 'dependabot[bot]'. Para obter mais informações, confira "Avaliar expressões em fluxos de trabalho e ações". - Modifique seus fluxos de trabalho para usar um processo de duas etapas que inclui
pull_request_targetque não tem essas limitações. Para obter mais informações, confira "Automatizando o Dependabot com GitHub Actions". - Forneça fluxos de trabalho disparados pelo acesso do Dependabot aos segredos e permita que o termo
permissionsaumente o escopo padrão doGITHUB_TOKEN.
Some troubleshooting advice is provided in this article. You can also see Sintaxe de fluxo de trabalho para o 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 Configurando o acesso a registros privados para 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 Usar segredos em ações do GitHub.
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 Automatizando o Dependabot com 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 Autenticação automática de token.
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 Reexecutando fluxos de trabalho e trabalhos.