Les vérifications d’état indiquent si les validations répondent aux conditions définies pour un référentiel. Elles sont généralement créées par des systèmes externes, tels que des builds d’intégration continue, des tests, une analyse du code ou des vérifications de déploiement.
Les vérifications d’état aident les réviseurs et les maintenances à comprendre si une demande de tirage est prête à être fusionnée. Une vérification peut indiquer que le travail est toujours en cours d’exécution, que les modifications ont réussi la validation ou que quelque chose a besoin d’attention.
Toute personne disposant d’autorisations d’écriture dans un référentiel peut définir l’état pour toute vérification d’état dans le référentiel.
Si les vérifications d’état sont requises pour une branche protégée, elles doivent passer avant que la demande de tirage puisse être fusionnée. Consultez « À propos des branches protégées ».
Remarque
Un travail ignoré signale son état comme « Réussite ». Il n’empêche pas une demande de tirage (pull request) de fusionner, même s’il s’agit d’une vérification requise.
Types de vérifications d’état sur GitHub
Il existe deux types de vérifications d’état sur GitHub:
| Type | Niveau de détail | Créé par |
|---|---|---|
| Contrôles | Sortie détaillée, annotations et messages. | |
| GitHub Apps, y compris GitHub Actions. | ||
| États de validation | Un état plus simple pour une validation. | Services externes et intégrations. |
Remarque
GitHub Actions génère des vérifications, et non des états de validation, quand les flux de travail sont exécutés.
Les propriétaires et utilisateurs de l’organisation disposant d’un accès Push à un référentiel peuvent créer des vérifications et valider des états avec GitHubl’API . Consultez Points de terminaison d’API REST pour les vérifications et Points de terminaison de l’API REST pour les statuts de commit.
Contrôles
Les vérifications peuvent inclure des journaux de génération, des résultats de test, des annotations et des liens vers plus de détails. Dans une demande de tirage, l’onglet Vérifications vous aide à comprendre les validations exécutées et pourquoi une vérification a réussi ou échoué.
Remarque
L’onglet Vérifications est renseigné pour les demandes de tirage uniquement si vous configurez des vérifications, et non des états de validation, pour le référentiel.
Lorsqu’une vérification pointe vers une ligne spécifique, les détails peuvent également apparaître sous l’onglet Fichiers de la demande de tirage. Cela permet aux réviseurs de connecter des commentaires automatisés au code en cours de modification.
Ignorer et demander des vérifications pour les validations individuelles
Certains référentiels permettent d’ignorer ou de demander des validations individuelles. Cela peut être utile lorsqu’une vérification n’est pas pertinente pour une modification spécifique ou lorsque les vérifications ne sont pas demandées automatiquement.
Pour GitHub Actions les flux de travail, vous pouvez ignorer les exécutions de flux de travail déclenchées par les push événements et pull_request en incluant une instruction skip dans votre message de validation. Consultez « Exécutions de workflow ignorées ».
Sinon, pour ignorer ou demander toutes les vérifications pour votre commit, ajoutez l’une des lignes de code de fin suivantes à la fin de votre message de commit :
-
Pour ignorer des vérifications pour une validation, entrez votre message de validation ainsi qu’une description courte et explicite de vos modifications. Après la description de votre validation, avant de fermer la quotation, ajoutez deux lignes vides suivies de
skip-checks: true:$ git commit -m "Update README > > skip-checks: true" -
Pour demander des vérifications pour une validation, entrez votre message de validation ainsi qu’une description courte et explicite de vos modifications. Après la description de votre validation, avant de fermer la quotation, ajoutez deux lignes vides suivies de
request-checks: true:$ git commit -m "Refactor usability tests > > request-checks: true"
Par défaut, Git supprime automatiquement les sauts de ligne consécutifs. Pour laisser le message de validation exactement comme vous l’avez saisi, utilisez l’option --cleanup=verbatim sur votre validation. Pour plus d’informations, consultez --cleanup=<mode> dans la documentation Git.
Statuts de vérification et conclusions
Vérifie les états à mesure qu’ils s’exécutent, puis reçoivent une conclusion lorsqu’ils se terminent. Certains états ne peuvent pas être définis manuellement et sont réservés .GitHub Actions
| Status | Description |
GitHub Actions Seulement? |
| --- | --- | --- |
| completed | L’exécution de la vérification s’est achevée et a une conclusion (voir ci-dessous). | No |
| expected | L’exécution de la vérification attend qu’un statut soit signalé. | Oui |
| failure | L’exécution de la vérification a échoué. | No |
| in_progress | L’exécution de la vérification est en cours. | No |
| pending | L’exécution de la vérification se trouve au début de la file d’attente, mais la limite de concurrence basée sur un groupe a été atteinte. | Oui |
| queued | L’exécution de la vérification a été mise en file d’attente. | No |
| requested | L’exécution de la vérification a été créée, mais n’a pas été mise en file d’attente. | Oui |
| startup_failure | La suite de vérifications a échoué pendant le démarrage. Ce statut n’est pas applicable aux exécutions de vérification. | Oui |
| waiting | L’exécution de la vérification attend qu’une règle de protection de déploiement soit satisfaite. | Oui |
Lorsqu’une vérification affiche le statut completed, elle a une conclusion. Une conclusion réussie signifie généralement que la vérification ne bloque pas la fusion. Une conclusion d’échec, de délai d’expiration ou d’action requise signifie généralement qu’une personne doit passer en revue les détails avant que la demande de tirage puisse fusionner.
| Conclusion | Description |
|---|---|
action_required | L’exécution de la vérification a fourni les actions requises à son achèvement. Pour plus d’informations, consultez « Utilisation de l’API REST pour interagir avec des vérifications ». |
cancelled | L’exécution de la vérification a été annulée avant son achèvement. |
failure | L’exécution de la vérification a échoué. |
neutral | L’exécution de la vérification s’est achevée avec un résultat neutre. Cela est considéré comme un succès pour les vérifications dépendantes dans GitHub Actions. |
skipped | L’exécution de la vérification a été ignorée. Cela est considéré comme un succès pour les vérifications dépendantes dans GitHub Actions. |
stale | L’exécution de la vérification a été marquée obsolète car GitHub elle a pris trop de temps. |
success | L’exécution de la vérification s’est achevée avec succès. |
timed_out | L’exécution de la vérification a expiré. |
Conservation des vérifications
GitHub conserve les données de vérification pendant 400 jours. Au terme des 400 jours, les données sont archivées. 10 jours après l’archivage, les données sont définitivement supprimées.
Pour fusionner une pull request avec des contrôles à la fois obligatoires et archivés, vous devez relancer les contrôles.