Si vous disposez d’une vérification et d’un statut portant le même nom, et sélectionnez ce nom comme vérification de statut requise, la vérification et le statut sont obligatoires. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les vérifications ».
Remarque
Pour être obligatoire, les vérifications de statut doivent s'exécuter correctement dans le référentiel choisi durant les sept derniers jours.
Une que vous activé les vérifications de statut requises, il se peut que votre branche doive être mise à jour avec la branche de base avant la fusion. Cela garantit que votre branche a été testée avec le code le plus récent de la branche de base. Si votre branche est obsolète, vous devez la fusionner avec la branche de base. Pour plus d’informations, consultez « À propos des branches protégées ».
Remarque
Vous pouvez également synchroniser votre branche avec la branche de base à l’aide d’un rebase Git. Pour plus d’informations, consultez « À propos de git rebase ».
Vous ne pourrez pas pousser des modifications locales vers une branche protégée tant que tous les tests d'état requis n'auront pas été validés. Au lieu de cela, vous recevrez un message d’erreur similaire à celui-ci :
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
Remarque
Les pull requests qui sont à jour et qui passent les vérifications de statut requises peuvent être fusionnées localement et poussées vers la branche protégée. Cela peut être effectué sans que des vérifications d'état soient effectuées directement sur le commit de fusion lui-même.
La vérification requise doit réussir par rapport au dernier commit SHA
Pour qu'une demande de tirage soit fusionnée, toutes les vérifications requises doivent être effectuées sur la base du dernier commit SHA. Cela garantit que les modifications les plus récentes sont validées et répondent aux normes requises avant la fusion. Les vérifications qui ont été déclenchées en utilisant la validation SHA précédente ne seront pas utilisées dans le cadre des vérifications requises. Les états de vérification réussis sont les suivants : success, skipped et neutral. Pour plus d’informations, consultez « À propos des vérifications d’état ».
Conflits entre la validation principale et la validation de fusion test
Parfois, les résultats des vérifications de statut pour la validation de fusion test et la validation principale sont contradictoires. Si la validation de fusion test a un statut, elle doit aboutir. Autrement, le statut de la validation principale doit passer la vérification avant que vous puissiez fusionner la branche.
En cas de conflit entre le commit de fusion de test et le commit principal, les vérifications du commit de fusion de test sont affichées dans la section des contrôles d'état de la pull request. Cela est indiqué dans la zone d’état du pull request par une ligne commençant par Showing checks for the merge commit. Pour plus d’informations sur les commits de fusion test, consultez Points de terminaison d’API REST pour les pull requests.
Gestion des vérifications omises mais requises
Avertissement
Si un flux de travail est ignoré en raison du filtrage de chemin d’accès, du filtrage de branche ou d’un message de commit, les vérifications associées à ce flux de travail restent alors à l’état « En attente ». La fusion d'une pull request nécessitant la validation de ces vérifications sera bloquée.
Vous ne devez pas utiliser le filtrage de chemin d’accès ou de branche pour ignorer les exécutions de workflow si celui-ci doit aboutir avant la fusion. Pour plus d’informations, consultez « Exécutions de workflow ignorées » et « Règles disponibles pour les ensembles de règles ».
Si, toutefois, une tâche dans un workflow est ignorée en raison d’une condition, elle indiquera son état comme « Succès ». Pour plus d’informations, consultez « Utilisation de conditions pour contrôler l’exécution des travaux ».
En cas d’échec d’un travail, tous les travaux qui dépendent de celui ayant échoué sont ignorés et ne signalent pas d’échec. Une demande de tirage qui requiert la vérification ne peut pas être bloquée. Pour utiliser une vérification requise sur un travail qui dépend d'autres travaux, utilisez l’expression conditionnelle always() en plus de needs, consultez Utilisation de tâches dans un flux de travail.
Exemple
L’exemple suivant montre un workflow nécessitant un statut d'achèvement « Réussi » pour le travail build, mais le workflow sera ignoré si la pull request ne modifie aucun fichier dans le répertoire scripts.
name: ci
on:
pull_request:
paths:
- 'scripts/**'
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 14.x, 16.x]
steps:
- uses: actions/checkout@v5
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
En raison du filtrage de chemin d’accès, une demande de tirage qui modifie uniquement un fichier à la racine du dépôt ne déclenche pas ce workflow et sa fusion est bloquée. Sur la demande de tirage (pull request), le message « Waiting for status to be reported » (En attente d’affichage de l’état) apparaît.
Vous ne devez pas utiliser le filtrage de chemin d’accès ou de branche pour ignorer les exécutions de workflow si celui-ci doit aboutir avant la fusion. Pour plus d’informations, consultez « Exécutions de workflow ignorées » et « Règles disponibles pour les ensembles de règles ».
Vérifications d’état avec GitHub Actions et une file d’attente de fusion
Vous devez utiliser cet événement merge_group pour déclencher votre workflow GitHub Actions quand une pull request est ajoutée à la file d'attente de merges.
Remarque
Si votre référentiel utilise GitHub Actions pour effectuer des vérifications requises ou si vous avez besoin de workflows via des ensembles de règles d’organisation sur les demandes de tirage dans votre référentiel, vous devez mettre à jour les workflows pour inclure l’événement merge_group en tant que déclencheur supplémentaire. Autrement, les vérifications d’état ne seront pas déclenchées lorsque vous ajouterez une demande de tirage à une file d’attente de fusion. La fusion échouera, car la vérification d’état requise ne sera pas signalée. L’événement merge_group est distinct des événements pull_request et push.
Voici comment se présente un workflow qui signale une vérification requise par les protections de la branche cible :
on:
pull_request:
merge_group:
Pour plus d’informations sur l’événement merge_group, consultez Événements qui déclenchent des flux de travail.
Vérifications d’état nécessaires à partir de sources inattendues
Il est également possible qu’une branche protégée exige une vérification de statut d’une GitHub App spécifique. Si vous voyez un message similaire au suivant, vous devez vérifier que l'opération répertoriée dans la boîte de fusion a été réalisée par l'application prévue.
Required status check "build" was not set by the expected GitHub App.