Flux de travail de résolution des problèmes

Suggestions initiales pour le dépannage

Il existe plusieurs façons de résoudre les problèmes liés à l'échec de l'exécution d'un flux de travail.

Using workflow run logs

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

Enabling debug logging

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 « Enabling debug logging ».

Si votre flux de travail utilise des outils ou des actions spécifiques, l’activation de leurs options de journalisation détaillées ou de débogage peut vous aider à générer une sortie plus détaillée pour la résolution des problèmes. Par exemple, vous pouvez utiliser npm install --verbose pour npm ou GIT_TRACE=1 GIT_CURL_VERBOSE=1 git ... pour Git.

Dépannage des déclencheurs de flux de travail

Vous pouvez passer en revue le champ on: de votre flux de travail pour comprendre ce qui est attendu pour déclencher le flux de travail. 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 ».

Déclenchement de conditions d’événement

Certains événements déclencheurs s’exécutent uniquement à partir de la branche par défaut (c’est-à-dire issues, schedule). Les versions de fichiers de flux de travail qui existent en dehors de la branche par défaut ne se déclenchent pas sur ces événements.

Les workflows ne s'exécutent pas sur une activité pull_request si la demande de tirage (pull request) a un conflit de fusion.

Les flux de travail qui seraient déclenchés dans push ou l’activité pull_request seront ignorés si le message de validation contient une annotation ignorer. Pour plus d’informations, consultez « Exécutions de workflow ignorées ».

Flux de travail planifiés en cours d’exécution à des moments inattendus

Les événements planifiés peuvent être retardés pendant les périodes de forte charge des exécutions du workflow GitHub Actions.

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 différences

Des événements spécifiques permettent de filtrer par branche, balise et/ou chemins que vous pouvez personnaliser. La création de l’exécution du flux de travail est ignorée si les conditions de filtre s’appliquent pour filtrer le flux de travail.

Vous pouvez utiliser des caractères spéciaux avec des filtres. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Pour le filtrage des chemins d’accès, l’évaluation des différences est limitée aux 300 premiers fichiers. Si des fichiers modifiés ne correspondent pas aux 300 premiers fichiers renvoyés par le filtre, le workflow ne sera pas exécuté. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Dépannage de l'exécution du flux de travail

L’exécution du flux de travail implique tous les problèmes observés après le déclenchement du flux de travail et l’exécution d’un flux de travail a été créée.

Annulation des flux de travail

Si l’annulation standard par le biais de l’interface utilisateur ou de l’API ne traite pas comme prévu, une instruction conditionnelle peut être configurée pour votre ou vos travaux de flux de travail en cours d’exécution qui l’entraînent à ne pas annuler.

Dans ces cas, vous pouvez tirer parti de 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 courante peut être l'utilisation de always()la fonction de vérification d'état qui renvoie true, même en cas d'annulation. Une alternative consiste à utiliser l'inverse de la cancelled() fonction, ${{ !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 ».

Résolution des problèmes liés aux exécuteurs

Définition d’étiquettes d’exécuteur

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

Nous vous recommandons d’utiliser des noms d’étiquettes uniques pour les exécuteurs plus volumineux et auto-hébergés. Si une étiquette correspond à l’une des étiquettes prédéfinies existantes, il peut y avoir des problèmes d’affectation d’exécuteur lorsqu’il n’existe aucune garantie sur laquelle l’option d’exécuteur correspondante sur laquelle le travail s’exécute.

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