Résoudre les problèmes d’exécution de pipeline

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Si l'exécution de votre pipeline ne parvient pas à se terminer, vous pouvez utiliser les informations de diagnostic et les journaux fournis par la page de résumé de l'exécution du pipeline pour vous aider à résoudre le problème.

Capture d'écran de la page récapitulative de l'exécution du pipeline.

Afficher les journaux d’activité

Sélectionnez le message d'erreur pour afficher les journaux de la tâche qui n'a pas abouti.

Capture d'écran du message d'erreur de la tâche sur la page de résumé de l'exécution du pipeline.

La page des journaux s'affiche, avec l'erreur sélectionnée. Dans cet exemple, il y a une erreur dans la tâche cmd-line, où la commande echo est entrée sous la forme ech.

Capture d'écran du journal de diagnostic de l'exécution du pipeline.

Vous pouvez afficher le journal brut de la tâche en choisissant Afficher le journal brut et vous pouvez rechercher le journal à l'aide de Rechercher.

Capture d'écran des options d'affichage du journal dans Azure DevOps.

Analysez les journaux de la tâche ayant échoué pour obtenir des informations sur les erreurs et des indices expliquant pourquoi la tâche échoue. Par défaut, les journaux non détaillés sont générés par une exécution de pipeline. Si les journaux par défaut n'indiquent pas la cause du problème, vous pouvez obtenir plus d'informations en configurant des journaux détaillés.

Page d'analyse des erreurs

Une assistance au dépannage est disponible à l’aide de la page Analyse des erreurs. Déplacez la souris sur la ligne d'informations sur l'erreur et choisissez l'icône Afficher l'analyse.

Capture d'écran de l'icône d'analyse de l'affichage sur la page de résumé de l'exécution du pipeline.

Capture d'écran de l'icône d'analyse de la vue pour Azure DevOps Server.

Choisissez Afficher l'agent pour les agents auto-hébergés (ou À propos de l'image de l'agent hébergé pour les agents hébergés par Microsoft) pour afficher plus d'informations sur l'agent utilisé pour exécuter le pipeline, et Afficher le journal pour afficher les journaux d'exécution du pipeline.

Capture d'écran de la page d'analyse des erreurs dans le portail Azure DevOps.

Choisissez le nom de la tâche sous Détails d'exécution pour afficher des informations sur la tâche.

Capture d'écran des détails de la tâche à partir de l'analyse des erreurs.

Dans cet exemple, vous pouvez voir qu'il y a une erreur Value dans le fichier Script. Choisissez À propos de cette tâche pour afficher la documentation de la tâche.

Si le problème n'apparaît pas dans la page de résumé de l'exécution du pipeline ou dans les journaux, consultez la section Problèmes courants suivante et consultez Examiner les journaux pour diagnostiquer les problèmes de pipeline pour obtenir des informations sur le téléchargement de journaux complets qui incluent des informations de diagnostic supplémentaires.

Problèmes courants

Aperçus de tâches pour les échecs d'exécution de pipeline

Azure DevOps fournit un paramètre Aperçus des tâches pour les exécutions de pipeline ayant échoué qui, lorsqu’il est activé, fournit des notifications contextuelles concernant les échecs de génération, avec un lien permettant d’afficher un rapport.

Capture d’écran des mesures d’aperçus de tâches.

Pour configurer ce paramètre, accédez à Fonctionnalités en préversion, recherchez Aperçus des tâches pour les exécutions de pipeline échoué, choisissez ensuite le paramètre souhaité.

Capture d’écran des aperçus de tâches pour le paramètre d’exécutions de pipeline défaillant.

Délai d’attente d’un travail

Un pipeline peut fonctionner pendant une longue période, puis échouer en raison d'un délai d'attente d'une tâche. Le délai d'expiration de la tâche dépend étroitement de l'agent utilisé. Les agents hébergés gratuitement par Microsoft ont un délai d’expiration maximal de 60 minutes par travail pour un dépôt privé et de 360 minutes pour un référentiel public. Pour augmenter le délai d’expiration maximal d’un travail, vous pouvez opter pour l’une des options suivantes.

  • Acheter un agent hébergé par Microsoft qui vous donnera 360 minutes pour tous les travaux, quel que soit le référentiel utilisé
  • Utiliser un agent autohébergé pour exclure tout problème de délai d’attente dû à l’agent

En savoir plus sur le délai d’expiration du travail.

Remarque

Si vos travaux d’agent hébergés par Microsoft expirent, vérifiez que vous n’avez pas spécifié de délai d’expiration du pipeline inférieur au délai d’expiration maximal d’un travail. Pour vérifier, consultez Délais d’expiration.

Problèmes de téléchargement du code

Mon pipeline échoue lors d’une étape de validation

Si vous utilisez une étape checkout sur un référentiel Git Azure Repos dans votre organisation qui se trouve dans un projet différent de votre pipeline, assurez-vous que le paramètre Limiter la portée de l'autorisation de travail au projet actuel est désactivé, ou suivez les étapes dans Identités de build étendues pour vous assurer que votre pipeline a accès au référentiel.

Lorsque votre pipeline ne peut pas accéder au référentiel en raison d’une étendue d’autorisation de travail limitée, vous recevez l’erreur Git fetch failed with exit code 128 et vos journaux contiennent une entrée similaire à Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Si votre pipeline échoue immédiatement avec Could not find a project that corresponds with the repository, assurez-vous que le nom de votre projet et de votre référentiel sont corrects dans l’étape checkout ou la déclaration de ressource du référentiel.

Problèmes Team Foundation Version Control (TFVC)

Obtenir des sources qui ne téléchargent pas certains fichiers

Cela peut être caractérisé par un message dans le journal "Tous les fichiers à jour" provenant de la commande tf get. Vérifiez que l’identité de service intégrée est autorisée à télécharger les sources. Le service de build de collection de projets d’identité ou le service de build de projet doivent être autorisés à télécharger les sources, en fonction de l’étendue d’autorisation sélectionnée sous l’onglet Général du pipeline de build. Dans l’interface utilisateur web du contrôle de version, vous pouvez parcourir des fichiers projet à n’importe quel niveau de la hiérarchie des dossiers et cliquer la case des paramètres de sécurité.

Obtenir des sources via le proxy Team Foundation

Le moyen le plus simple de configurer l’agent pour obtenir des sources via un proxy Team Foundation consiste à définir la variable d’environnement TFSPROXY pointant vers le serveur proxy TFVC pour l’exécution de l’agent en tant qu’utilisateur.

Windows :

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

Mac OS/Linux :

    export TFSPROXY=http://tfvcproxy:8081

Échec de mon pipeline lors d’une étape de ligne de commande telle que MSBUILD

Il est utile de déterminer si un échec de build ou de mise en production est le résultat d’un problème de produit Azure Pipelines/TFS (agent ou tâches). Les échecs de build et de publication peuvent également résulter de commandes externes.

Vérifiez dans les journaux la ligne de commande exacte exécutée par la tâche défaillante. Tenter d'exécuter la commande localement à partir de la ligne de commande peut reproduire le problème. Il peut être utile d'exécuter la commande localement à partir de votre propre ordinateur et/ou de vous connecter à l'ordinateur et d'exécuter la commande en tant que compte de service.

Par exemple, le problème se produit-il pendant la partie MSBuild de votre pipeline de build (par exemple, utilisez-vous la tâche MSBuild ou Visual Studio Build) ? Si c’est le cas, essayez d’exécuter la même commande MSBuild sur un ordinateur local à l’aide des mêmes arguments. Si vous pouvez reproduire le problème sur votre ordinateur local, les étapes suivantes consistent à examiner le problème MSBuild.

Disposition de fichiers

L'emplacement des outils, bibliothèques, en-têtes et autres éléments nécessaires à une génération peut être différent sur l'agent hébergé et sur votre ordinateur local. Si une build échoue parce qu’elle ne trouve pas l’un de ces fichiers, vous pouvez utiliser les scripts ci-dessous pour inspecter la disposition sur l’agent. Cela pourrait vous aider à retrouver le fichier manquant.

Créez un pipeline YAML dans un emplacement temporaire (par exemple, un nouveau référentiel créé à des fins de résolution des problèmes). Tel qu’il est écrit, le script recherche les répertoires de votre chemin d’accès. Vous pouvez éventuellement modifier la ligne SEARCH_PATH= pour rechercher d'autres endroits.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Différences entre l’invite de commandes locale et l’agent

Gardez à l’esprit que certaines différences sont appliquées lors de l’exécution d’une commande sur un ordinateur local et lorsqu’une build ou une mise en production est en cours d’exécution sur un agent. Si l’agent est configuré pour s’exécuter en tant que service sur Linux, macOS ou Windows, il ne s’exécute pas dans une session interactive connectée. Sans session interactive de connexion, l’interaction de l’interface utilisateur et d’autres limitations existent.

Erreurs de fichier ou de dossier en cours d’utilisation

File or folder in use les erreurs sont souvent indiquées par des messages d’erreur tels que :

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Procédure de résolution :

Détecter les fichiers et dossiers en cours d’utilisation

Sur Windows, des outils tels que Analyseur de processus peuvent être utilisés pour capturer une trace des événements de fichier dans un répertoire spécifique. Ou, pour une capture instantanée dans le temps, des outils tels que Explorateur de processus ou Descripteur peuvent être utilisés.

Exclusion antivirus

Les logiciels antivirus qui analysent vos fichiers peuvent provoquer des erreurs de fichier ou de dossier en cours d’utilisation lors d’une build ou d’une mise en production. L'ajout d'une exclusion antivirus pour le répertoire de votre agent et le « dossier de travail » configuré peut aider à identifier le logiciel antivirus comme étant le processus interférant.

MSBuild et /nodeReuse:false

Si vous appelez MSBuild pendant votre build, veillez à passer l’argument /nodeReuse:false (forme /nr:false abrégée). Sinon, les processus MSBuild resteront en cours d’exécution une fois la construction terminée. Les processus restent en suspens pendant un certain temps en prévision d'une éventuelle construction ultérieure.

Cette fonctionnalité de MSBuild peut interférer avec les tentatives de suppression ou de déplacement d’un répertoire, en raison d’un conflit avec le répertoire de travail du ou des processus MSBuild.

Les tâches MSBuild et Visual Studio Build ajoutent déjà /nr:false aux arguments passés à MSBuild. Toutefois, si vous appelez MSBuild à partir de votre propre script, vous devez spécifier l’argument.

MSBuild and /maxcpucount:[n]

Par défaut, les tâches de génération telles que MSBuild et Visual Studio Build exécutent MSBuild avec le commutateur /m. Dans certains cas, cela peut entraîner des problèmes tels que des problèmes d’accès à plusieurs fichiers de processus.

Essayez d’ajouter l’argument /m:1 à vos tâches de build pour forcer MSBuild à exécuter un seul processus à la fois.

Des problèmes d’utilisation de fichiers peuvent survenir lors de l’exploitation de la fonctionnalité de processus simultanés de MSBuild. Le fait de ne pas spécifier l’argument /maxcpucount:[n] (forme /m:[n]abrégée) indique à MSBuild d’utiliser un seul processus. Si vous utilisez les tâches MSBuild ou Visual Studio Build, vous devrez peut-être spécifier « /m:1 » pour remplacer l'argument « /m » ajouté par défaut.

Échecs MSBuild intermittents ou incohérents

Si vous rencontrez des échecs MSBuild intermittents ou incohérents, essayez de demander à MSBuild d’utiliser un seul processus. Des erreurs intermittentes ou incohérentes peuvent indiquer que votre configuration cible est incompatible avec la fonctionnalité de processus simultané de MSBuild. Consultez MSBuild et /maxcpucount:[n].

Le processus cesse de répondre

Le processus cesse de répondre aux causes et aux étapes de résolution des problèmes :

En attente d'entrée

Un processus qui cesse de répondre peut indiquer qu'un processus attend une entrée.

L'exécution de l'agent à partir de la ligne de commande d'une session interactive connectée peut aider à identifier si un processus demande une boîte de dialogue de saisie.

L’exécution de l’agent en tant que service peut aider à empêcher les programmes de demander des entrées. Par exemple, dans .NET, les programmes peuvent s'appuyer sur le booléen System.Environment.UserInteractive pour déterminer s'ils doivent demander une invite. Lorsque l’agent s’exécute en tant que service Windows, la valeur est false.

Vidage du processus

L’analyse d’un vidage du processus peut aider à identifier ce qu’un processus bloqué attend.

Projet WiX

La génération d’un projet WiX lorsque les enregistreurs d’événements MSBuild personnalisés sont activés peut entraîner un interblocage de WiX en attente sur le flux de sortie. L’ajout de l’argument /p:RunWixToolsOutOfProc=true MSBuild supplémentaire permet de contourner le problème.

Fins de ligne pour plusieurs plateformes

Lorsque vous exécutez des pipelines sur plusieurs plateformes, vous pouvez parfois rencontrer des problèmes avec différentes terminaisons de ligne. Historiquement, Linux et macOS utilisaient des caractères de saut de ligne (LF), tandis que Windows utilisait un retour chariot plus un saut de ligne (CRLF). Git tente de compenser la différence en faisant automatiquement en sorte que les lignes se terminent en LF dans le référentiel, mais en CRLF dans le répertoire de travail sur Windows.

La plupart des outils Windows sont parfaits avec les terminaisons LF uniquement et ce comportement automatique peut provoquer plus de problèmes qu’il ne résout. Si vous rencontrez des problèmes basés sur des fins de ligne, nous vous recommandons de configurer Git pour préférer LF partout. Pour l’activer, ajoutez un fichier .gitattributes à la racine de votre référentiel. Dans ce fichier, ajoutez la ligne suivante :

* text eol=lf

Variables avec ' (guillemet unique) ajouté

Si votre pipeline inclut un script Bash qui définit des variables à l'aide de la commande ##vso, vous verrez peut-être un ajout ' supplémentaire à la valeur de la variable que vous définissez. Cela survient en raison d’une interaction avec set -x. La solution consiste à désactiver temporairement set -x avant de définir une variable. Afin d’effectuer cette opération, la syntaxe Bash est set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Pourquoi cela se produit-il ?

De nombreux scripts Bash incluent la commande set -x pour faciliter le débogage. Bash trace exactement la commande qui a été exécutée et la renvoie à stdout. Ainsi, l’agent verra la commande ##vso deux fois et la deuxième fois, Bash aura ajouté le caractère ' à la fin.

Pour instance, considérez ce pipeline :

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

Sur stdout, l’agent voit deux lignes :

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Lorsque l’agent voit la première ligne, MY_VAR est défini sur la valeur correcte, « my_value ». Toutefois, lorsqu’il voit la deuxième ligne, l’agent traite tout jusqu’à la fin de la ligne. MY_VAR sera défini sur « my_value ».

Les bibliothèques ne sont pas installées pour l’application Python lorsque le script s’exécute

Lorsqu’une application Python est déployée, dans certains cas, un pipeline CI/CD s’exécute et le code est déployé correctement, mais le fichier requirements.txt responsable de l’installation de toutes les bibliothèques de dépendances ne s’exécute pas.

Pour installer les dépendances, utilisez un script de post-déploiement dans la tâche de déploiement App Service. L’exemple suivant montre la commande que vous devez utiliser dans le script de post-déploiement. Vous pouvez mettre à jour le script pour votre scénario.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Pour résoudre les problèmes liés aux connexions de service, consultez Résolution des problèmes de connexion de service.

Le pipeline a perdu la communication avec l'agent

Si votre pipeline échoue avec un message semblable à We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., vérifiez l'utilisation des ressources de l'agent pour voir si la machine de l'agent n'est pas à court de ressources. En commençant par le Sprint 228, les journaux d'Azure Pipelines contiennent des mesures d'utilisation des ressources pour chaque étape.

Lorsque vous utilisez les services Azure DevOps, vous pouvez voir l'utilisation des ressources dans les journaux, comme l'utilisation du disque, de la mémoire et du processeur, en activant les journaux détaillés. Lorsque le pipeline est terminé, recherchez les journaux pour les entrées Agent environment resources pour chaque étape.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Pour plus d'informations sur la capture de journaux d'utilisation des ressources supplémentaires, voir Capturer les détails de l'utilisation des ressources.

Activer Explorateur Stockage pour déployer du contenu statique comme .css et .js sur un site web statique à partir d’Azure DevOps via Azure Pipelines

Dans ce scénario, vous pouvez utiliser la tâche de copie de fichiers Azure pour charger du contenu sur le site web. Vous pouvez utiliser l’un des outils décrits dans Charger du contenu pour charger du contenu dans le conteneur web.

Étapes suivantes