Skip to main content

Résolution des problèmes de Dependabot sur GitHub Actions

Cet article fournit des informations sur la résolution des problèmes que vous pouvez rencontrer lors de l’utilisation de Dependabot avec GitHub Actions.

Restrictions lorsque Dependabot déclenche des événements

Dependabot est en mesure de déclencher des workflows GitHub Actions sur ses demandes de tirage requêtes et commentaires ; toutefois, certains événements sont traités différemment.

Pour les workflows lancés par Dependabot (github.actor == 'dependabot[bot]') en utilisant les événements pull_request, pull_request_review, pull_request_review_comment, push, create, deployment et deployment_status, ces restrictions s’appliquent :

  • GITHUB_TOKEN dispose d’autorisations en lecture seule par défaut.
  • Les secrets sont remplis à partir des secrets Dependabot. Les secrets GitHub Actions ne sont pas disponibles.

Pour les workflows lancés par Dependabot (github.actor == 'dependabot[bot]') en utilisant l’événement pull_request_target, si la référence de base de la demande de tirage a été créée par Dependabot (github.event.pull_request.user.login == 'dependabot[bot]'), le GITHUB_TOKEN est en lecture seule et les secrets ne sont pas disponibles.

Ces restrictions s’appliquent même si le workflow est réexécuté par un autre acteur.

Pour plus d’informations, consultez Maintien de la sécurité de votre instance GitHub Actions et de vos flux de travail : Prévention des demandes pwn.

Résolution des défaillances quand Dependabot déclenche des workflows existants

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 « Résolution des problèmes de Dependabot sur 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.

Certains conseils de dépannage sont fournis dans cet article. Vous pouvez également consulter Workflow syntax for GitHub Actions.

Accès aux secrets

Quand un événement Dependabot déclenche un workflow, les seuls secrets disponibles pour le workflow sont les secrets Dependabot. Les secrets GitHub Actions sont indisponibles. Vous devez donc stocker tous les secrets utilisés par un workflow déclenché par des événements Dependabot en tant que secrets Dependabot. Pour plus d’informations, consultez « Configuration de l’accès aux registres privés pour Dependabot ».

Les secrets Dependabot sont ajoutés au contexte secrets et référencés avec exactement la même syntaxe que les secrets pour GitHub Actions. Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».

Si vous disposez d’un workflow destiné à être déclenché par Dependabot et par d’autres acteurs, la solution la plus simple consiste à stocker le jeton avec les autorisations requises dans une action et dans un secret Dependabot portant des noms identiques. Ensuite, le workflow peut inclure un seul appel à ces secrets. Si le secret pour Dependabot a un nom différent, utilisez des conditions pour spécifier les secrets corrects que doivent utiliser les différents acteurs.

Pour obtenir des exemples qui utilisent des conditions, consultez Automatisation de Dependabot avec GitHub Actions.

Pour accéder à un registre de conteneurs privé sur AWS avec un nom d’utilisateur et un mot de passe, un workflow doit inclure un secret pour username et password.

Dans cet exemple, quand Dependabot déclenche le workflow, les secrets Dependabot portant les noms READONLY_AWS_ACCESS_KEY_ID et READONLY_AWS_ACCESS_KEY sont utilisés. Si un autre acteur déclenche le workflow, les secrets d’actions portant ces noms sont utilisés.

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)

Changement des autorisations GITHUB_TOKEN

Par défaut, les workflows GitHub Actions déclenchés par Dependabot obtiennent un GITHUB_TOKEN avec des autorisations de lecture seule. Vous pouvez utiliser la clé permissions dans votre workflow afin d’augmenter l’accès pour le jeton :

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

Pour plus d’informations, consultez « Authentification par jeton automatique ».

Réexécution manuelle d’un workflow

Lorsque vous réexécutez manuellement un workflow Dependabot, celui-ci s’exécute avec les mêmes privilèges qu’avant même si l’utilisateur qui a lancé la réexécution a des privilèges différents. Pour plus d’informations, consultez « Ré-exécution de workflows et de travaux ».