Flux de travail de résolution des problèmes

Vous pouvez utiliser les outils dans GitHub Actions pour déboguer vos flux de travail.

Dans cet article

Suggestions initiales pour la résolution des problèmes

Il existe plusieurs manières de remédier aux problèmes d'échec de l'exécution d'un flux de travail.

Remarque

Si vous êtes sur un GitHub Copilot gratuit abonnement, cela compte pour votre limite de message de conversation mensuelle.

Utilisation de GitHub Copilot

Pour ouvrir un chat avec GitHub Copilot à propos d’une exécution de workflow ayant échoué, vous pouvez :

  • À côté de la vérification ayant échoué dans l’encadré de fusion, cliquez sur , puis cliquez sur Expliquer l’erreur.
  • 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.

Cela ouvre une fenêtre de discussion avec GitHub Copilot, dans laquelle des instructions seront fournies pour résoudre le problème.

Utilisation des journaux d’exécution de flux de travail

Chaque 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 ».

Activation de la journalisation du débogage

Si 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 ».

Si 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. Par exemple, vous pouvez utiliser npm install --verbose pour npm ou GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ... pour Git.

Vérification des erreurs de facturation

L’utilisation de GitHub Actions inclut les minutes de runner et le stockage des artefacts de workflow. Pour plus d’informations, consultez « Facturation des actions GitHub ».

Définir un budget

Dé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.

Analyse de GitHub Actions activité à l’aide de métriques

Pour analyser l’efficacité et la fiabilité de vos workflows à l'aide des métriques, consultez « Affichage des mesures des GitHub Actions ».

Dépannage des déclencheurs de workflow

Vous 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 ».

Pour obtenir la liste complète des événements disponibles, consultez Événements qui déclenchent des flux de travail.

Conditions de déclenchement de l’événement

Certains é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.

Les workflows ne s’exécutent pas sur une activité pull_request si la demande de tirage a un conflit de fusion.

Les 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 ».

Workflows planifiés s’exécutant à des heures inattendues

Les é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.

Les 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 ».

Limites de filtrage et de comparaison (diff)

Certains é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.

Vous pouvez utiliser des caractères spéciaux avec des filtres. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Pour 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 ».

Dépannage de l'exécution du workflow

L’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.

Conditions des travaux de débogage

Si 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 :

  1. Cliquez sur le travail dans l’exécution du workflow.
  2. Téléchargez l’archive des fichiers journaux à partir du menu du travail.
  3. Ouvrez le fichier JOB-NAME/system.txt .
  4. Recherchez les lignes Evaluating, Expanded, et Result.

La 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.

Pour plus d’informations, consultez « Affichage des journaux d’expressions de conditions des tâches ».

Annulation de workflows

Si l’annulation standard par le biais de l’interface utilisateur ou de l’API 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.

Dans 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 ».

Une cause fréquente peut être l’utilisation de la always()fonction de vérification de l'état qui renvoie true, même en cas d’annulation. Une alternative consiste à utiliser l'inverse de la fonction cancelled(), ${{ !cancelled() }}.

Pour plus d’informations, consultez « Utilisation de conditions pour contrôler l’exécution des travaux » et « Annulation d’une exécution de workflow ».

Dépannage des runners

Définition des étiquettes de runner

GitHub-les exécuteurs hébergés tirent parti des étiquettes prédéfinies gérées par le biais du actions/runner-images référentiel.

Nous 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.

Exécuteurs auto-hébergés

Si vous utilisez des exécuteurs auto-hébergés, vous pouvez afficher leur activité et diagnostiquer les problèmes courants.

Pour plus d’informations, consultez « Surveillance des exécuteurs auto-hébergés et résolution des problèmes ».

Adresses IP du runner signalées par les scanners de sécurité

GitHubLes 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 ».

Les 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.

GitHub 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.

Si 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).

Suggestions de dépannage réseau

Notre assistance est limitée pour les problèmes réseau impliquant :

  • Vos réseaux
  • Réseaux externes
  • Systèmes tiers
  • Connectivité Internet générale

Pour afficher l’état en temps réel de la plateforme de GitHub, consultez GitHubStatus.

Pour 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.

Si 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.

DNS

Des 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.

Pare-feu

Les 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.

Proxies

Des 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.

Consultez Utilisation de serveurs proxy avec un exécuteur pour en savoir plus sur la configuration de l’application du runner afin d’utiliser un proxy.

Sous-réseaux

Il 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.

Certificats

Des 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.

Listes d’adresses IP

Les 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.

Pour plus d’informations sur les adresses IP de GitHub, telles que celles utilisées par les exécuteurs hébergés de GitHub, consultez À propos des adresses IP de GitHub.

Les 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 pour plus d'informations.

Systèmes d’exploitation et applications logicielles

En 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.

Réseau privé Azure pour les runners hébergés par GitHub

Des 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).

Pour 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 ou Dépannage des configurations de réseau privé Azure pour les runners hébergés par GitHub dans votre entreprise dans la GitHub Enterprise Clouddocumentation.