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 :
- 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 des expressions dans les workflows et les actions. ». - Vous pouvez modifier vos workflows de sorte qu’ils utilisent un processus en deux étapes qui comprend
pull_request_targetqui ne présente pas ces limites. Pour plus d’informations, consultez « Résolution des problèmes de Dependabot sur GitHub Actions ». - 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 deGITHUB_TOKEN.
Cet article fournit quelques conseils de résolution des problèmes. Vous pouvez également consulter la section Syntaxe de flux de travail pour 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 ne sont pas disponibles. 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 des exemples qui utilisent des conditions, veuillez consulter la section 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.
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
name: CI
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v5
- 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)
# Ce workflow utilise des actions qui ne sont pas certifiées par GitHub.
# Elles sont fournies par un tiers et régies par
# des conditions d’utilisation du service, une politique de confidentialité et un support distincts.
# documentation en ligne.
name: CI
on:
pull_request:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v5
- 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 :
name: CI on: pull_request # Set the access for individual scopes, or use permissions: write-all permissions: pull-requests: write issues: write ... jobs: ...
name: CI
on: pull_request
# Set the access for individual scopes, or use permissions: write-all
permissions:
pull-requests: write
issues: write
...
jobs:
...
Pour plus d’informations, consultez « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».
Réexécution manuelle d’un workflow
Lorsque vous relancez manuellement un workflow Dependabot, il s'exécute avec les mêmes privilèges qu'auparavant, même si l'utilisateur qui a lancé la relance dispose de privilèges différents. Pour plus d’informations, consultez « Ré-exécution de workflows et de tâches ».