{"meta":{"title":"Flux de travail de résolution des problèmes","intro":"Vous pouvez utiliser les outils dans GitHub Actions pour déboguer vos flux de travail.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/how-tos","title":"Guides pratiques"},{"href":"/fr/actions/how-tos/troubleshoot-workflows","title":"Résoudre les problèmes liés aux workflows"}],"documentType":"article"},"body":"# Flux de travail de résolution des problèmes\n\nVous pouvez utiliser les outils dans GitHub Actions pour déboguer vos flux de travail.\n\n## Suggestions initiales pour la résolution des problèmes\n\nIl existe plusieurs manières de remédier aux problèmes d'échec de l'exécution d'un flux de travail.\n\n> \\[!NOTE] Si vous êtes sur un GitHub Copilot Free abonnement, cela compte pour votre limite de message de conversation mensuelle.\n\n### Utilisation de GitHub Copilot\n\nPour ouvrir un chat avec GitHub Copilot à propos d’une exécution de workflow ayant échoué, vous pouvez :\n\n* À côté de la vérification ayant échoué dans l’encadré de fusion, cliquez sur ****, puis cliquez sur ** Expliquer l’erreur**.\n* Dans la zone de fusion, cliquez sur la vérification ayant échoué. En haut de la page récapitulative de l’exécution du flux de travail, cliquez sur ** Expliquer l’erreur**.\n\nCela ouvre une fenêtre de discussion avec GitHub Copilot, dans laquelle des instructions seront fournies pour résoudre le problème.\n\n### Utilisation des journaux d’exécution de flux de travail\n\nChaque exécution de workflow génère des journaux d’activité que vous pouvez afficher, investiguer et télécharger. Pour plus d’informations, consultez « [Utilisation des journaux d’exécution de flux de travail](/fr/actions/how-tos/monitor-workflows/use-workflow-run-logs) ».\n\n### Activation de la journalisation du débogage\n\nSi les journaux de workflow ne fournissent pas suffisamment de détails pour diagnostiquer la raison pour laquelle un workflow, un travail ou une étape ne fonctionne pas comme prévu, vous pouvez activer une journalisation de débogage supplémentaire. Pour plus d’informations, consultez « [Activation de la journalisation du débogage](/fr/actions/how-tos/monitor-workflows/enable-debug-logging) ».\n\nSi votre workflow utilise des outils ou des actions spécifiques, l’activation de leurs options de débogage ou de journalisation détaillée peut aider à générer des sorties plus détaillées pour le dépannage.\nPar exemple, vous pouvez utiliser `npm install --verbose` pour npm ou `GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ...` pour Git.\n\n## Vérification des erreurs de facturation\n\nL’utilisation de GitHub Actions inclut les minutes de runner et le stockage des [artefacts de workflow](/fr/actions/tutorials/store-and-share-data). Pour plus d’informations, consultez « [Facturation des actions GitHub](/fr/billing/concepts/product-billing/github-actions) ».\n\n### Définir un budget\n\nDéfinir un budget Actions peut aider à débloquer immédiatement des workflows qui échouent en raison d’erreurs de facturation ou de stockage. Cela permettra de facturer l’utilisation supplémentaire de minutes et de stockage jusqu’au montant du budget défini. Pour en savoir plus, consultez [Configurer des budgets pour contrôler les dépenses liées aux produits facturés à l’usage](/fr/billing/how-tos/set-up-budgets).\n\n## Analyse de GitHub Actions activité à l’aide de métriques\n\nPour analyser l’efficacité et la fiabilité de vos workflows à l'aide des métriques, consultez « [Affichage des mesures des GitHub Actions](/fr/actions/how-tos/administer/view-metrics) ».\n\n## Dépannage des déclencheurs de workflow\n\nTout d’abord, vérifiez que votre flux de travail n’a pas été désactivé manuellement, consultez [Désactivation et activation d’un workflow](/fr/actions/how-tos/manage-workflow-runs/disable-and-enable-workflows). Un flux de travail désactivé ne répond pas à ses déclencheurs.\n\nVous pouvez passer en revue le champ `on:` de votre workflow afin de comprendre ce qui est censé le déclencher. Pour plus d’informations, consultez « [Déclenchement d’un workflow](/fr/actions/how-tos/write-workflows/choose-when-workflows-run/trigger-a-workflow) ».\n\nPour obtenir la liste complète des événements disponibles, consultez [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows).\n\n### Conditions de déclenchement de l’événement\n\nCertains événements déclencheurs s’exécutent uniquement à partir de la branche par défaut (à savoir `issues`, `schedule`). Les versions du fichier de workflow qui existent en dehors de la branche par défaut ne seront pas déclenchées par ces événements.\n\nLes workflows ne s’exécutent pas sur une activité `pull_request` si la demande de tirage a un conflit de fusion.\n\nLes workflows qui seraient déclenchés par l’événement `push` ou l’activité `pull_request` seront ignorés si le message de commit contient une annotation d’ignorance. Pour plus d’informations, consultez « [Exécutions de workflow ignorées](/fr/actions/how-tos/manage-workflow-runs/skip-workflow-runs) ».\n\n### Workflows planifiés s’exécutant à des heures inattendues\n\nLes événements planifiés peuvent être retardés pendant des périodes de charges élevées d’exécutions de flux de GitHub Actions travail.\n\nLes périodes de charges élevées incluent le début de chaque heure. Si la charge est suffisamment élevée, certains travaux en file d’attente peuvent être supprimés. Pour réduire le risque de retard, planifiez l’exécution de votre workflow à un autre moment dans l’heure. Pour plus d’informations, consultez « [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule) ».\n\n### Limites de filtrage et de comparaison (diff)\n\nCertains événements permettent un filtrage personnalisable par branche, balise et/ou chemins. La création de l’exécution du workflow sera ignorée si les conditions de filtrage s’appliquent de manière à exclure le workflow.\n\nVous pouvez utiliser des caractères spéciaux avec des filtres. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet) ».\n\nPour le filtrage par chemins, l’évaluation des différences (diffs) est limitée aux 300 premiers fichiers. S’il y a des fichiers modifiés qui ne sont pas mis en correspondance dans les 300 premiers fichiers retournés par le filtre, le workflow n’est pas exécuté. Pour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#git-diff-comparisons) ».\n\n## Dépannage de l'exécution du workflow\n\nL’exécution du workflow englobe tous les problèmes observés après le déclenchement du workflow et la création d’une exécution de workflow.\n\n### Conditions des travaux de débogage\n\nSi un travail a été ignoré de manière inattendue, ou s’il s’est exécuté alors que vous vous attendiez à ce qu’il soit ignoré, vous pouvez consulter l’évaluation de l’expression afin de comprendre pourquoi :\n\n1. Cliquez sur le travail dans l’exécution du workflow.\n2. Téléchargez l’archive des fichiers journaux à partir du menu du travail.\n3. Ouvrez le fichier `JOB-NAME/system.txt` .\n4. Recherchez les lignes `Evaluating`, `Expanded`, et `Result`.\n\nLa ligne `Expanded` montre les valeurs d’exécution réelles qui ont été substituées dans votre condition `if`, expliquant clairement pourquoi l’expression a été évaluée à `true` ou à `false`.\n\nPour plus d’informations, consultez « [Affichage des journaux d’expressions de conditions des tâches](/fr/actions/how-tos/monitor-workflows/view-job-condition-logs) ».\n\n### Annulation de workflows\n\nSi l’annulation standard par le biais de [l’interface utilisateur](/fr/actions/reference/workflows-and-actions/workflow-cancellation) ou de [l’API](/fr/rest/actions/workflow-runs?apiVersion=2022-11-28#cancel-a-workflow-run) ne fonctionne pas comme prévu, il se peut qu’une instruction conditionnelle soit configurée pour le ou les jobs du workflow en cours, empêchant leur annulation.\n\nDans ces cas, vous pouvez utiliser l’API pour forcer l’annulation de l’exécution. Pour plus d’informations, consultez « [Points de terminaison d'API REST pour l'exécution des workflows](/fr/rest/actions/workflow-runs?apiVersion=2022-11-28#force-cancel-a-workflow-run) ».\n\nUne cause fréquente peut être l’utilisation de la `always()`[fonction de vérification de l'état](/fr/actions/reference/workflows-and-actions/expressions#status-check-functions) qui renvoie `true`, même en cas d’annulation. Une alternative consiste à utiliser l'inverse de la fonction `cancelled()`, `${{ !cancelled() }}`.\n\nPour plus d’informations, 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) » et « [Annulation d’une exécution de workflow](/fr/actions/how-tos/manage-workflow-runs/cancel-a-workflow-run) ».\n\n## Dépannage des runners\n\n### Définition des étiquettes de runner\n\nLes exécuteurs hébergés sur GitHub tirent parti [des étiquettes prédéfinies](/fr/actions/reference/runners/github-hosted-runners#standard-github-hosted-runners-for-public-repositories) gérées par le biais du référentiel [`actions/runner-images`](https://github.com/actions/runner-images?tab=readme-ov-file#available-images).\n\nNous recommandons d’utiliser des noms d’étiquettes uniques pour les runners de grande taille et les runners auto-hébergés. Si une étiquette correspond à l’une des étiquettes prédéfinies existantes, des problèmes d’attribution de runner peuvent survenir, sans garantie quant au runner correspondant sur lequel le travail s’exécutera.\n\n### Exécuteurs auto-hébergés\n\nSi vous utilisez des exécuteurs auto-hébergés, vous pouvez afficher leur activité et diagnostiquer les problèmes courants.\n\nPour plus d’informations, consultez « [Surveillance des exécuteurs auto-hébergés et résolution des problèmes](/fr/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot) ».\n\n### Adresses IP du runner signalées par les scanners de sécurité\n\nGitHubLes runners hébergés utilisent des adresses IP attribuées dynamiquement issues d’une infrastructure partagée. Ces adresses IP sont publiées via l’API Meta (par exemple, les clés `actions` et `actions_macos`). Pour plus d’informations, consultez « [Points de terminaison d’API REST pour les métadonnées](/fr/rest/meta/meta#get-github-meta-information) ».\n\nLes services de renseignement sur les menaces tiers, les scanneurs de réputation IP ou les fournisseurs de pare-feu peuvent marquer ces adresses IP comme « malveillantes » ou « suspectes ». Étant donné que l’infrastructure sous-jacente est partagée, l’activité d’autres utilisateurs de la même infrastructure peut influencer les scores de réputation attribués à ces adresses.\n\nGitHub ne contrôle pas les listes de réputation IP tierces et ne peut pas commenter leur précision ou leur fréquence de mise à jour. Pour vérifier si une adresse IP appartient aux runners hébergés par GitHub, consultez les plages d’adresses IP renvoyées par l’API Meta.\n\nSi vous avez une préoccupation de sécurité concernant une adresse IP appartenant à Microsoft, signalez-la à la [Centre d'intervention en matière de sécurité Microsoft (MSRC)](https://msrc.microsoft.com/report/).\n\n## Suggestions de dépannage réseau\n\nNotre assistance est limitée pour les problèmes réseau impliquant :\n\n* Vos réseaux\n* Réseaux externes\n* Systèmes tiers\n* Connectivité Internet générale\n\nPour afficher l’état en temps réel de la plateforme de GitHub, consultez [GitHubStatus](https://githubstatus.com/).\n\nPour les autres problèmes liés au réseau, examinez les paramètres réseau de votre organisation et vérifiez l’état des services tiers auxquels vous accédez. Si les problèmes persistent, envisagez de contacter vos administrateurs réseau pour obtenir une assistance supplémentaire.\n\nSi vous n’êtes pas sûr du problème, contactez Support GitHub. Pour en savoir plus sur la manière de contacter le support, consultez [Contacter le support GitHub](/fr/support/contacting-github-support).\n\n### DNS\n\nDes problèmes peuvent survenir en raison de la configuration du système de noms de domaine (DNS), de la résolution DNS ou de problèmes de résolveur. Nous vous recommandons d’examiner les journaux disponibles, la documentation du fournisseur ou de consulter vos administrateurs pour obtenir une assistance supplémentaire.\n\n### Pare-feu\n\nLes activités peuvent être bloquées par des pare-feux. Si cela se produit, vous pouvez examiner les journaux disponibles, la documentation du fournisseur ou consulter vos administrateurs pour obtenir une assistance supplémentaire.\n\n### Proxies\n\nDes activités peuvent échouer lors de l’utilisation d’un proxy pour les communications. Il est recommandé de consulter les journaux disponibles, la documentation du fournisseur ou de faire appel à vos administrateurs pour obtenir une assistance supplémentaire.\n\nConsultez [Utilisation de serveurs proxy avec un exécuteur](/fr/actions/how-tos/manage-runners/use-proxy-servers) pour en savoir plus sur la configuration de l’application du runner afin d’utiliser un proxy.\n\n### Sous-réseaux\n\nIl est possible de rencontrer des problèmes liés à des sous-réseaux utilisés ou à des chevauchements avec un réseau existant, par exemple au sein d’un fournisseur de cloud virtuel ou de réseaux Docker. Dans ce cas, nous vous recommandons d’examiner votre topologie réseau et les sous-réseaux utilisés.\n\n### Certificats\n\nDes problèmes peuvent survenir en raison de chaînes de certificats auto-signées ou personnalisées, ainsi que des magasins de certificats. Vous pouvez vérifier que le certificat utilisé n’a pas expiré et qu’il est actuellement approuvé. Les certificats peuvent être inspectés à l’aide de `curl` ou d’outils similaires. Vous pouvez également examiner les journaux disponibles, la documentation du fournisseur ou de consulter vos administrateurs pour obtenir une assistance supplémentaire.\n\n### Listes d’adresses IP\n\nLes listes d’autorisation ou de refus d’adresses IP peuvent perturber les communications attendues. En cas de problème, vous devez examiner les journaux disponibles, la documentation du fournisseur ou consulter vos administrateurs pour obtenir une assistance supplémentaire.\n\nPour plus d’informations sur les adresses IP de GitHub, telles que celles utilisées par les exécuteurs hébergés sur GitHub, consultez [À propos des adresses IP de GitHub](/fr/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses).\n\nLes adresses IP statiques peuvent être utilisées avec des exécuteurs de plus grande taille hébergés sur GitHub. Consultez [Gestion des exécuteurs de plus grande taille](/fr/actions/how-tos/manage-runners/larger-runners/manage-larger-runners) pour plus d'informations.\n\n### Systèmes d’exploitation et applications logicielles\n\nEn plus des pare-feu ou des proxys, les personnalisations effectuées sur GitHubdes exécuteurs hébergés, telles que l’installation de packages logiciels supplémentaires, peuvent entraîner des interruptions de communication. Pour en savoir plus sur les options de personnalisation disponibles, consultez [Personnalisation des runners hébergés par GitHub](/fr/actions/how-tos/manage-runners/github-hosted-runners/customize-runners).\n\n* Pour les runners auto-hébergés, consultez plus d’informations sur les points de terminaison nécessaires dans [Documentation de référence relative aux runners auto-hébergés](/fr/actions/reference/runners/self-hosted-runners).\n\n* Pour obtenir de l’aide au niveau de la configuration de WireGuard, consultez [Utilisation de WireGuard pour créer un réseau de superposition](/fr/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-wireguard).\n\n* Pour en savoir plus sur la configuration d’OpenID Connect (OIDC), consultez [Utilisation d’une passerelle API avec OIDC](/fr/actions/how-tos/manage-runners/github-hosted-runners/connect-to-a-private-network/connect-with-oidc).\n\n### Réseau privé Azure pour les runners hébergés par GitHub\n\nDes problèmes peuvent survenir en raison de l’utilisation de runners hébergés par GitHub dans la configuration de vos réseaux virtuels Azure (VNET).\n\nPour obtenir des conseils de dépannage, consultez [Résolution des problèmes de configurations de réseau privé Azure pour les exécuteurs GitHub hébergés dans votre organisation](/fr/organizations/managing-organization-settings/troubleshooting-azure-private-network-configurations-for-github-hosted-runners-in-your-organization) ou [Dépannage des configurations de réseau privé Azure pour les runners hébergés par GitHub dans votre entreprise](/fr/enterprise-cloud@latest/admin/configuring-settings/configuring-private-networking-for-hosted-compute-products/troubleshooting-azure-private-network-configurations-for-github-hosted-runners-in-your-enterprise) dans la GitHub Enterprise Clouddocumentation."}