Troubleshooting Dependabot on GitHub Actions

This article provides troubleshooting information for issues you may encounter when using Dependabot with GitHub Actions.

Dans cet article

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

Après avoir configuré les mises à jour Dependabot pour votre instance GitHub Enterprise Server, il se peut que constatiez des défaillances quand des workflows existants sont déclenchés par des événements Dependabot.

Par défaut, les exécutions de workflows GitHub Actions qui sont déclenchées par Dependabot à partir d’événements push, pull_request, pull_request_review ou pull_request_review_comment ont considérées comme ayant été ouvertes à partir d’une duplication (fork) de dépôt. Contrairement aux workflows déclenchés par d’autres acteurs, cela signifie qu’ils reçoivent un GITHUB_TOKEN en lecture seule et qu’ils n’ont pas accès aux secrets qui sont normalement disponibles. Ainsi, les flux de travail qui tentent d’écrire dans le dépôt échouent quand ils sont déclenchés par Dependabot.

Il existe trois façons de résoudre ce problème :

  1. Vous pouvez mettre à jour vos workflows de sorte qu’ils ne soient plus déclenchés par Dependabot en utilisant une expression de ce type : if: github.actor != 'dependabot[bot]'. Pour plus d’informations, consultez « Évaluer les expressions dans les workflows et les actions ».
  2. Vous pouvez modifier vos workflows de sorte qu’ils utilisent un processus en deux étapes qui comprend pull_request_target qui ne présente pas ces limites. Pour plus d’informations, consultez « Automatisation de Dependabot avec GitHub Actions ».
  3. Vous pouvez permettre aux workflows déclenchés par Dependabot d’accéder aux secrets et autoriser le terme permissions à augmenter l’étendue par défaut de GITHUB_TOKEN.

Some troubleshooting advice is provided in this article. You can also see Workflow syntax for 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 Configuration de l’accès aux registres privés pour 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 Utilisation de secrets dans 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 Automatisation de Dependabot avec 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.

YAML
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:

YAML
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 Authentification par jeton automatique.

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 Ré-exécution de workflows et de travaux.