{"meta":{"title":"Résolution des problèmes liés aux vérifications de statut requises","intro":"Résolvez les erreurs courantes et débloquez la fusion ou le push vers des branches protégées en résolvant les problèmes liés aux vérifications d’état requises.","product":"Demandes de tirage","breadcrumbs":[{"href":"/fr/pull-requests","title":"Demandes de tirage"},{"href":"/fr/pull-requests/how-tos","title":"Guide pratique"},{"href":"/fr/pull-requests/how-tos/merge-and-close-pull-requests","title":"Fusionner et fermer"},{"href":"/fr/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks","title":"Résoudre les problèmes liés aux vérifications d’état"}],"documentType":"article"},"body":"# Résolution des problèmes liés aux vérifications de statut requises\n\nRésolvez les erreurs courantes et débloquez la fusion ou le push vers des branches protégées en résolvant les problèmes liés aux vérifications d’état requises.\n\nUtilisez ces vérifications lorsqu’une vérification d’état requise empêche la fusion ou le push vers une branche protégée. Consultez « [Vérifications d'état](/fr/pull-requests/reference/status-checks) ».\n\n* Une vérification d’état requise doit avoir été effectuée avec succès dans le référentiel choisi au cours des sept derniers jours.\n* Si une vérification et un état de validation ont le même nom, les deux doivent passer lorsque ce nom est requis. Consultez « [Points de terminaison d’API REST pour les vérifications](/fr/rest/checks) ».\n* Si la protection des branches nécessite que votre branche soit up-to-date, fusionnez ou rebasez la branche de base dans votre branche. Consultez [À propos des branches protégées](/fr/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging) et [À propos de git rebase](/fr/get-started/using-git/about-git-rebase).\n\nSi les vérifications d’état requises n’ont pas réussi, le push vers une branche protégée renvoie une erreur similaire à celle-ci.\n\n```shell\nremote: error: GH006: Protected branch update failed for refs/heads/main.\nremote: error: Required status check \"ci-build\" is failing\n```\n\n> \\[!NOTE]\n> 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. Vous pouvez le faire sans exécuter de vérifications de statut sur le commit de fusion lui-même.\n\n## La vérification requise doit réussir par rapport au dernier commit SHA\n\nVérifiez les points suivants si une vérification requise bloque toujours une pull request.\n\n* Les vérifications requises doivent réussir sur le dernier SHA du commit. Les vérifications issues de commits antérieurs ne satisfont pas à l’exigence.\n* Les états de vérification réussi sont `success`, `skipped`et `neutral`. Consultez « [Vérifications d'état](/fr/pull-requests/reference/status-checks) ».\n\n## Conflits entre le commit principal et le commit de fusion de test\n\nUtilisez la zone des contrôles d’état de la pull request pour identifier quel commit doit réussir les contrôles.\n\n| Source de vérification de l’état             | Qu’est-ce qui doit passer ? | Ce que vous pouvez voir               |\n| -------------------------------------------- | --------------------------- | ------------------------------------- |\n| Le commit de fusion de test a un statut      | Le commit de fusion de test | `Showing checks for the merge commit` |\n| Le commit de fusion de test n’a aucun statut | Le commit de tête           | Vérifie le dernier commit de HEAD     |\n\nConsultez « [Points de terminaison d’API REST pour les pull requests](/fr/rest/pulls/pulls#get-a-pull-request) ».\n\n## Gestion des vérifications omises mais requises\n\n| Cause                                                                                                                                                                                                                                                                                                                                                                                                                    | Résultat                                                                             | Guide pratique pour corriger ou vérifier                                                                                                                                                                                                                         |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Un flux de travail est ignoré par [le filtrage des chemins](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore), [le filtrage des branches](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ou un [message de commit](/fr/actions/how-tos/manage-workflow-runs/skip-workflow-runs) | Les vérifications associées restent dans l’état « En attente » et bloquent la fusion | Évitez d’exiger des flux de travail qui peuvent être ignorés.                                                                                                                                                                                                    |\n| Une tâche est ignorée en raison d’une condition                                                                                                                                                                                                                                                                                                                                                                          | Le travail signale « Réussite »                                                      | Consultez « [Utilisation de conditions pour contrôler l’exécution des travaux](/fr/actions/how-tos/write-workflows/choose-when-workflows-run/control-jobs-with-conditions) ».                                                                                    |\n| Un travail dépend d’un travail ayant échoué                                                                                                                                                                                                                                                                                                                                                                              | Le travail dépendant est ignoré et peut ne pas bloquer la fusion                     | Utilisez `always()` avec `needs` pour les vérifications requises qui dépendent d’autres tâches. Consultez « [Utilisation de tâches dans un flux de travail](/fr/actions/how-tos/write-workflows/choose-what-workflows-do/use-jobs#defining-prerequisite-jobs) ». |\n\n### Exemple\n\nCe flux de travail nécessite un job `build` réussi, mais ne s’exécute que lorsqu’une pull request modifie des fichiers dans `scripts`.\n\n```yaml\nname: ci\non:\n  pull_request:\n    paths:\n      - 'scripts/**'\njobs:\n  build:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node-version: [12.x, 14.x, 16.x]\n    steps:\n    - uses: actions/checkout@v6\n    - name: Use Node.js ${{ matrix.node-version }}\n      uses: actions/setup-node@v7\n      with:\n        node-version: ${{ matrix.node-version }}\n        cache: 'npm'\n    - run: npm ci\n    - run: npm run build --if-present\n    - run: npm test\n```\n\nUne pull request qui modifie uniquement un fichier à la racine du référentiel ne déclenchera pas ce flux de travail. Si `build` est nécessaire, la requête de tirage est bloquée avec le message « En attente que l’état soit signalé. »\n\n### Vérifications d’état avec GitHub Actions et file d’attente de fusion\n\nSi une file d’attente de fusion nécessite une GitHub Actions vérification, déclenchez le flux de travail avec l’événement `merge_group` .\n\n> \\[!NOTE]\n> Si votre référentiel utilise GitHub Actions pour effectuer des vérifications requises 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`.\n\nExemple de configuration de déclencheur :\n\n```yaml\non:\n  pull_request:\n  merge_group:\n```\n\nConsultez « [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows#merge_group) ».\n\n## Vérifications d’état nécessaires à partir de sources inattendues\n\nUne branche protégée peut également nécessiter une vérification d’état à partir d’un élément spécifique GitHub App. Si vous voyez un message similaire à ce qui suit, vérifiez que la case à cocher répertoriée dans la zone de fusion a été définie par l’application attendue.\n\n```text\nRequired status check \"build\" was not set by the expected GitHub App.\n```"}