Partager via

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

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

Si l’exécution de votre pipeline échoue, utilisez les informations de diagnostic et les journaux sur la page récapitulative de l’exécution du pipeline pour résoudre le problème. Ce guide fournit des instructions pour diagnostiquer les défaillances de pipeline à l’aide des journaux, des outils d’analyse des erreurs et des techniques de résolution des problèmes courantes. Découvrez comment identifier les causes racines et implémenter des solutions pour que vos pipelines s’exécutent en douceur.

Capture d’écran de la page résumé de l’exécution du pipeline avec des informations de diagnostic.

Afficher les journaux d’activité

Sélectionnez le message d’erreur pour afficher les journaux de la tâche incomplète.

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

La page des journaux système affiche l’erreur qui a été sélectionnée. Dans cet exemple, il existe une erreur dans la cmd-line tâche, où la echo commande est entrée en tant que ech.

Capture d’écran du journal des diagnostics pour 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 défaillante pour obtenir des informations d’erreur et des indices sur la raison de l’échec de la tâche. Par défaut, des journaux peu détaillés sont générés lors d'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 les journaux détaillés.

Page Analyse des erreurs

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

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

Capture d’écran de l’icône d’analyse d’affichage pour Azure DevOps Server.

Choisissez Afficher l’agent pour les agents auto-hébergés (ou Consulter l’image d’agent hébergé pour les agents hébergés par Microsoft) pour obtenir plus d’informations sur l’agent utilisé pour exécuter le pipeline, et Afficher le journal pour examiner 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 les détails de l’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 dans le Value du Script. Choisissez À propos de cette tâche pour afficher la documentation de la tâche.

Si le problème n’est pas apparent à partir de la page récapitulative de l’exécution du pipeline ou en parcourant les journaux d'activité, consultez la section Problèmes courants ci-dessous et voir Comment examiner les journaux pour diagnostiquer les problèmes de pipeline pour savoir comment télécharger les journaux d’activité complets qui contiennent des informations diagnostiques supplémentaires.

Problèmes courants

Analyses des exécutions de pipeline ayant échoué

Azure DevOps fournit un paramètre Task Insights pour les exécutions de pipeline ayant échoué , qui, lorsqu’il est activé, fournit des notifications contextuelles des échecs de build avec un lien pour afficher un rapport.

Capture d’écran des métriques Task Insights.

Pour configurer ce paramètre, accédez aux fonctionnalités d’aperçu, recherchez Task Insights pour les exécutions de pipeline ayant échoué, puis choisissez le paramètre souhaité.

Capture d’écran des informations sur l’échec des exécutions du pipeline dans le paramètre.

Notifications pour les exécutions ayant échoué

Azure DevOps inclut des notifications intégrées pour les exécutions de pipeline ayant échoué. Pour activer les notifications :

  1. Accédez aux paramètres du projet>Notifications pour votre projet.
  2. Choisissez le type de notification que vous souhaitez recevoir. Pour être averti chaque fois qu’une exécution du pipeline échoue, sélectionnez Une build échoue.

Capture d’écran des notifications dans les paramètres du projet.

Ce pipeline a besoin d’une autorisation pour accéder à une ressource avant que cette exécution puisse continuer

Si votre pipeline ne semble pas démarrer ou si vous recevez un message d'erreur comme This pipeline needs permission to access a resource before this run can continue, vérifiez si le pipeline attend une autorisation d'exécution par une ressource, comme une connexion de service ou un pool d'agents.

  1. Accédez au pipeline et démarrez manuellement une exécution.
  2. Le message suivant apparaît : Ce pipeline a besoin de la permission d’accéder à une ressource avant que cette exécution puisse continuer. Sélectionnez Afficher à côté du message.
  3. Sur l’écran En attente de révision, sélectionnez Autoriser, puis sur l’écran de confirmation, sélectionnez à nouveau Autoriser.

Cette action ajoute explicitement le pipeline en tant qu’utilisateur autorisé de la ressource.

Il existe deux façons d’autoriser les pipelines à accéder à votre pool d’agents.

Autoriser des pipelines spécifiques

Vous pouvez autoriser individuellement des pipelines spécifiques à s’exécuter dans un pool d’agents en suivant la procédure décrite dans la section précédente lorsque vous recevez un message comme This pipeline needs permission to access a resource before this run can continue.

Vous pouvez également ajouter et supprimer manuellement des pipelines de la liste autorisée en effectuant la procédure suivante. Cette procédure est effectuée au niveau du projet dans votre organisation Azure DevOps.

  1. Dans Azure DevOps, accédez aux paramètres du projet, pools d’agents, choisissez votre pool auto-hébergé, puis choisissez Sécurité.
  2. Choisissez + pour ajouter un pipeline à la liste autorisée.
  3. Choisissez X(Révoquer l’accès) pour supprimer un pipeline de la liste autorisée.

Configurer l’accès ouvert

Certaines ressources vous permettent de configurer Open Access afin que chaque nouvelle définition de pipeline ne nécessite pas d’autorisation explicite.

La configuration d’Open Access nécessite des autorisations d’administrateur de projet .

Pour configurer Open Access pour les pools d’agents :

  1. Dans Azure DevOps, accédez aux paramètres du projet, pools d’agents, choisissez votre pool auto-hébergé, puis choisissez Sécurité.
  2. Choisissez Plus d’actions, Ouvrir l’accès pour activer l’accès ouvert et choisissez à nouveau Ouvrir l’accès pour confirmer.
  3. Pour révoquer l’accès ouvert, choisissez Restreindre l’autorisation.

Pour vérifier si Open Access est disponible pour d’autres types de ressources, consultez Gérer la sécurité dans Azure Pipelines et rechercher Open Access.

Pour plus d’informations sur Open Access pour les pools d’agents, consultez Définir des autorisations de pipeline pour un pool d’agents individuel et des autorisations de pipeline.

Délai d’expiration du travail

Un pipeline peut s’exécuter pendant un certain temps, puis échouer en raison de l'expiration du délai de la tâche. L'expiration du délai de la tâche dépend étroitement de l'agent en cours d'utilisation. Les agents gratuits hébergés 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 dépôt public.

Pour augmenter le délai d’expiration maximal d’un travail, vous pouvez choisir l’un des éléments suivants.

  • Acheter un agent hébergé par Microsoft qui vous donne 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 tâches d’agent hébergées par Microsoft expirent, vérifiez que le délai d'expiration de votre pipeline est défini sur une valeur supérieure au délai d'expiration maximal d'une tâche. 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 checkout étape sur un dépôt Git Azure Repos dans votre organisation qui se trouve dans un projet différent de celui de votre pipeline, vérifiez que l’étendue d’autorisation de travail limite au paramètre de projet actuel est désactivée ou suivez les étapes décrites dans les identités de build délimitées 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 recevrez l’erreur Git fetch failed with exit code 128 et vos journaux contiennent une entrée similaire à celle de 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, vérifiez que le nom de votre projet et du référentiel est correct à l’étape checkout ou à la déclaration de ressource du référentiel.

Problèmes liés au contrôle de version Team Foundation (TFVC)

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

Vous pourriez voir un message dans le journal de bord « 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 d’identité Project Collection Build Service ou le Project Build Service doit être autorisé à télécharger les sources, selon l’étendue d’autorisation sélectionnée dans 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 Team Foundation Proxy

Le moyen le plus simple de configurer l’agent pour obtenir des sources via un proxy Team Foundation est de définir une variable TFSPROXY d’environnement qui pointe 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

Mon pipeline échoue sur une étape de ligne de commande telle que MSBUILD

Il est utile de limiter si une défaillance de build ou de mise en production est le résultat d’un problème de produit Azure Pipelines (agent ou tâches). Les échecs de génération et de mise en production peuvent également résulter de commandes externes.

Vérifiez les journaux pour la ligne de commande exacte exécutée par la tâche défaillante. Une tentative d’exécution de 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 ) ? Dans ce 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 un ordinateur local, vos étapes suivantes sont d’examiner le problème MSBuild .

Disposition des fichiers

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

Créez un pipeline YAML dans un emplacement temporaire (par exemple, un nouveau dépôt créé à des fins de résolution des problèmes). Tel que prévu, le script recherche des répertoires sur votre chemin. Vous pouvez éventuellement modifier la SEARCH_PATH= ligne pour rechercher d’autres emplacements.

# 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 logiciel

Gardez à l’esprit que certaines différences sont en vigueur lors de l’exécution d’une commande sur un ordinateur local et lorsqu’une build ou une version 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 connectée, l’interaction avec l’interface utilisateur et d’autres limitations existent.

Erreurs d’utilisation du fichier ou du dossier

File or folder in use les erreurs sont 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, les outils comme Process Monitor peuvent être pour capturer une trace d’événements de fichier sous un répertoire spécifique. Ou, pour un instantané dans le temps, des outils tels que Process Explorer ou Handle peuvent être utilisés.

Exclusion d'anti-virus

L’analyse logicielle antivirus de vos fichiers peut entraîner des erreurs d’utilisation de fichiers ou de dossiers lors d’une génération ou d’une version. L’ajout d’une exclusion antivirus pour votre répertoire d’agent et le « dossier de travail » configuré peuvent aider à identifier les logiciels antivirus comme processus d’interférence.

MSBuild et /nodeReuse : false

Si vous appelez MSBuild pendant votre build, veillez à passer l’argument /nodeReuse:false (formulaire /nr:falsecourt). Sinon, les processus MSBuild continuent à s’exécuter une fois la build terminée. Les processus restent pendant un certain temps dans l'attente d'une version potentiellement 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 des processus MSBuild.

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

MSBuild et /maxcpucount :[n]

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

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

Les problèmes liés aux fichiers en cours d’utilisation peuvent se produire lors de l’utilisation de la fonctionnalité de processus simultané de MSBuild. Le fait de ne pas spécifier l’argument /maxcpucount:[n] (court formulaire /m:[n]) 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 d’indiquer à MSBuild d’utiliser un seul processus. Des erreurs intermittentes ou incohérentes peuvent indiquer que votre configuration cible n’est pas compatible 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 affiche une boîte de dialogue pour demander une entrée.

L’exécution de l’agent en tant que service peut aider à éliminer les programmes de l’invite d’entrée. Par exemple, dans .NET, les programmes peuvent s'appuyer sur System.Environment.UserInteractive booléen pour déterminer s'il faut afficher une invite. Lorsque l’agent s’exécute en tant que service Windows, la valeur est false.

Vidage de processus

L’analyse d’un fichier de vidage de processus peut aider à identifier ce qu’un processus en situation de blocage attend.

Projet WiX

La création d’un projet WiX lorsque des enregistreurs MSBuild personnalisés sont activés peut provoquer un interblocage de WiX en attente sur le flux de sortie. L’ajout de l’argument supplémentaire /p:RunWixToolsOutOfProc=true MSBuild contourne le problème.

Terminaisons 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 suivi d'un saut de ligne (CRLF). Git tente de compenser la différence en faisant automatiquement en sorte que les lignes se terminent par LF dans le référentiel, mais par CRLF dans le répertoire de travail sur Windows.

La plupart des outils Windows sont corrects avec les terminaisons LF uniquement, et ce comportement automatique peut entraîner plus de problèmes qu’il ne le résout. Si vous rencontrez des problèmes en fonction des terminaisons de ligne, nous vous recommandons de configurer Git pour préférer LF partout. Pour ce faire, ajoutez un .gitattributes fichier à la racine de votre référentiel. Dans ce fichier, ajoutez la ligne suivante :

* text eol=lf

Variables ayant ' (guillemet unique) ajoutés

Si votre pipeline inclut un script Bash qui définit des variables à l’aide de la ##vso commande, vous pouvez voir un autre ' ajout à 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 quelles commandes ont été exécutées et les affiche sur stdout. Cela amène l'agent à voir la commande ##vso deux fois, et la deuxième fois, Bash aura ajouté le caractère ' à la fin.

Par exemple, tenez compte de 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 sera réglée sur la valeur correcte, « my_value ». Toutefois, lorsqu’il aperçoit la deuxième ligne, l’agent analyse tout jusqu’à la fin de la ligne. MY_VAR est 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 n’est pas exécuté.

Pour installer les dépendances, utilisez un script 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 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. Pour résoudre spécifiquement les problèmes de connexions de service à l’aide de l’identité de charge de travail pour l’authentification, consultez Résoudre les problèmes liés aux connexions de service d’identité de charge de travail.

Le pipeline n'a plus reçu de nouvelles de l'agent

Si votre pipeline échoue avec un message tel que 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 l’ordinateur de l’agent manque de ressources. À compter de Sprint 228, les journaux Azure Pipelines contiennent des métriques d’utilisation des ressources pour chaque étape.

Lorsque vous utilisez Azure DevOps Services, vous pouvez voir l’utilisation des ressources dans les journaux, notamment l’utilisation du disque, l’utilisation de la mémoire et l’utilisation du processeur, en activant les journaux détaillés. Une fois le pipeline terminé, recherchez les journaux d’activité pour Agent environment resources 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 savoir comment capturer des fichiers d'utilisation des ressources supplémentaires, consultez Capture des détails sur l'utilisation des ressources.

Activer l’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