# Résolution des problèmes liés aux vérifications de statut requises 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. Utilisez ces vérifications lorsqu’une vérification d’état requise empêche la fusion ou le push vers une branche protégée. Consultez « [Status checks](/fr/pull-requests/reference/status-checks) ». * 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. * 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) ». * 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). Si 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. ```shell remote: error: GH006: Protected branch update failed for refs/heads/main. remote: error: Required status check "ci-build" is failing ``` > \[!NOTE] > 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. ## La vérification requise doit réussir par rapport au dernier commit SHA Vérifiez les points suivants si une vérification requise bloque toujours une pull request. * 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. * Les états de vérification réussi sont `success`, `skipped`et `neutral`. Consultez « [Status checks](/fr/pull-requests/reference/status-checks) ». ## Conflits entre le commit principal et le commit de fusion de test Utilisez la zone des contrôles d’état de la pull request pour identifier quel commit doit réussir les contrôles. | Source de vérification de l’état | Qu’est-ce qui doit passer ? | Ce que vous pouvez voir | | -------------------------------------------- | --------------------------- | ------------------------------------- | | Le commit de fusion de test a un statut | Le commit de fusion de test | `Showing checks for the merge commit` | | Le commit de fusion de test n’a aucun statut | Le commit de tête | Vérifie le dernier commit de HEAD | Consultez « [Points de terminaison d’API REST pour les pull requests](/fr/rest/pulls/pulls#get-a-pull-request) ». ## Gestion des vérifications omises mais requises | Cause | Résultat | Guide pratique pour corriger ou vérifier | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 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. | | 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) ». | | 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) ». | ### Exemple Ce 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`. ```yaml 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@v6 - 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 ``` Une 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é. » ### Vérifications d’état avec GitHub Actions et file d’attente de fusion Si 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` . > \[!NOTE] > 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`. Exemple de configuration de déclencheur : ```yaml on: pull_request: merge_group: ``` Consultez « [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows#merge_group) ». ## Vérifications d’état nécessaires à partir de sources inattendues Une 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. ```text Required status check "build" was not set by the expected GitHub App. ```