Flux de travail de résolution des problèmes

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.

Utilisation de GitHub Copilot

Pour lancer un chat avec GitHub Copilot à propos de l’échec de l’exécution d’un workflow, vous pouvez soit :

• À côté de la vérification ayant échoué dans la zone 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 de résumé de l'exécution du workflow, cliquez sur Expliquer l'erreur.

Cela ouvre une fenêtre de chat avec GitHub Copilot, qui fournira des instructions afin de remédier au 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 « Using workflow run logs ».

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

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.

Examiner l’activité de GitHub Actions à 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

Scheduled Events peut être retardé pendant les périodes où les charges des exécutions de workflows GitHub Actions sont élevées.

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 les workflows runs ».

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

Les runners hébergés par GitHub utilisent des étiquettes prédéfinies gérées via le référentiel actions/runner-images.

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

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 consulter l'état en temps réel de la plateforme GitHub, consultez État de GitHub.

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 de l’origine 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 obtenir des informations sur les adresses IP de GitHub, notamment celles utilisées par les runners hébergés par GitHub, consultez À propos des adresses IP de GitHub.

Des adresses IP statiques sont disponibles pour une utilisation avec les runners de grande taille hébergés par 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 les runners hébergés par GitHub, telles que l’installation de packages logiciels supplémentaires, peuvent entraîner des perturbations des communications. Pour en savoir plus sur les options de personnalisation disponibles, consultez Personnalisation des exécuteurs hébergés par GitHub.

• Pour les runners auto-hébergés, consultez plus d’informations sur les points de terminaison nécessaires dans Référence des exécuteurs auto-hébergés.

• Pour obtenir de l’aide au niveau de la configuration de WireGuard, consultez Utilisation de WireGuard pour créer un réseau de superposition.

• Pour en savoir plus sur la configuration d’OpenID Connect (OIDC), consultez Utilisation d’une passerelle API avec OIDC.

Mise en réseau privée Azure pour les runners hébergés par GitHub

Des problèmes peuvent survenir lors de l’utilisation de runners hébergés par GitHub dans le cadre des paramètres de réseaux virtuels Azure (VNET) que vous avez configurés.

Pour obtenir des conseils de dépannage, consultez Dépannage des configurations réseau privé Azure pour les exécuteurs hébergés par GitHub dans votre organisation. ou Résolution des problèmes liés aux configurations de réseau privé Azure pour les exécuteurs hébergés par GitHub dans votre entreprise dans la documentation GitHub Enterprise Cloud.