Types de tâches et utilisation

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

Les travaux Azure Pipelines se composent d’étapes, qui peuvent être des tâches ou des scripts. Une tâche est un script ou une procédure prépackage qui effectue une action ou utilise un ensemble d’entrées pour définir l’automatisation du pipeline. Cet article décrit les tâches de pipeline et comment les utiliser. Pour plus d’informations sur le schéma, consultez la définition steps.task .

Azure Pipelines inclut de nombreuses tâches intégrées qui permettent des scénarios de génération et de déploiement fondamentaux. Pour obtenir la liste des tâches Azure Pipelines intégrées disponibles, consultez la référence des tâches Azure Pipelines. Vous pouvez également installer des tâches à partir de Visual Studio Marketplace ou créer des tâches personnalisées.

Par défaut, toutes les étapes d’un travail s’exécutent en séquence dans le même contexte, que ce soit sur l’hôte ou dans un conteneur de travaux. Vous pouvez éventuellement utiliser des cibles d’étape pour contrôler le contexte des tâches individuelles. Pour exécuter certaines tâches en parallèle sur plusieurs agents, ou sans utiliser d’agent, consultez Spécifier des travaux dans votre pipeline.

Gestion des tâches

Les tâches sont disponibles et installées au niveau de l’organisation Azure DevOps. Vous pouvez uniquement utiliser des tâches et des versions de tâches qui existent pour votre organisation.

Vous pouvez désactiver les tâches intégrées, les tâches de la Place de marché ou les deux dansles paramètres>des paramètres> de l’organisation sous restrictions de tâche. Si vous désactivez les tâches intégrées et marketplace, seules les tâches que vous installez à l’aide de l’interface CLI Node pour Azure DevOps sont disponibles.

La désactivation des tâches de la Place de marché peut contribuer à améliorer la sécurité des pipelines. Dans la plupart des cas, vous ne devez pas désactiver les tâches intégrées. Pour plus d’informations, consultez Contrôles disponibles.

Tâches personnalisées

Visual Studio Marketplace offre de nombreuses extensions que vous pouvez installer pour étendre le catalogue de tâches Azure Pipelines. Vous pouvez également créer des tâches personnalisées. Pour plus d’informations, consultez Ajouter une extension de tâche de pipelines personnalisée.

Dans les pipelines YAML, vous faites référence aux tâches par leur nom. Si votre nom de tâche personnalisé correspond à un nom de tâche intégré, le pipeline utilise la tâche intégrée. Pour éviter cette situation, vous pouvez référencer votre tâche personnalisée à l’aide du GUID de tâche unique que vous avez affecté lors de la création de la tâche. Pour plus d’informations, consultez Comprendre les composants task.json.

Versions des tâches

Les tâches sont mises en version et vous devez spécifier la version principale des tâches que vous utilisez dans votre pipeline. La spécification de la version permet d’éviter les problèmes lorsque de nouvelles versions d’une tâche sont publiées.

Les pipelines sont automatiquement mis à jour pour utiliser de nouvelles versions de tâches mineures, telles que 1.2 vers la version 1.3. Les versions mineures des tâches sont généralement rétrocompatibles, mais dans certains scénarios, vous risquez de rencontrer des erreurs imprévisibles lorsqu’une tâche est automatiquement mise à jour.

Si une nouvelle version de tâche majeure telle que les versions 2.0, votre pipeline continue d’utiliser la version principale que vous avez spécifiée jusqu’à ce que vous modifiez le pipeline pour passer manuellement à la nouvelle version principale. Les journaux de génération fournissent des alertes lorsque de nouvelles versions majeures sont disponibles. Vous pouvez uniquement utiliser des versions des tâches qui existent pour votre organisation.

YAML

Dans YAML, vous spécifiez la version principale à l’aide @ du nom de la tâche. Par exemple, pour utiliser la version 2 de la PublishTestResults tâche, spécifiez PublishTestResults@2. Vous pouvez spécifier la version mineure à utiliser en fournissant le numéro de version complet de la tâche après le @.GoTool@0.3.1

Classique

Dans les pipelines classiques, chaque tâche a un sélecteur de version pour vous permettre de choisir la version souhaitée. Envisagez de cloner le pipeline et de tester le pipeline cloné avec de nouvelles versions de tâches principales. Si vous sélectionnez une préversion telle que la préversion 1.* , la version est toujours en cours de développement et peut rencontrer des problèmes.

Si vous modifiez la version et que vous rencontrez des problèmes avec vos builds, vous pouvez rétablir la modification du pipeline à partir de l’onglet Historique . Pour les pipelines de mise en production, la possibilité de restaurer vers une version antérieure n’est pas disponible. Vous devez revenir manuellement sur les changements apportés au pipeline de mise en production, puis enregistrer le pipeline.

Options de tâche

YAML

Les propriétés suivantes sont disponibles pour les étapes de pipeline task YAML. Pour plus d’informations, consultez la définition steps.task .

Propriété	Type	Descriptif
task	ficelle	Obligatoire en tant que première propriété. Nom de la tâche à exécuter.
inputs	ficelle	Entrées pour la tâche, à l’aide de paires nom/valeur.
condition	ficelle	Conditions sous lesquelles la tâche s’exécute.
continueOnError	boolean	Indique s’il faut continuer à s’exécuter même en cas d’échec.
displayName	ficelle	Nom lisible par l’homme pour la tâche.
enabled	boolean	Indique s’il faut exécuter cette tâche lors de l’exécution du travail.
env	ficelle	Variables à mapper dans l’environnement de processus à l’aide de paires nom/valeur.
name	ficelle	ID de l’étape.
retryCountOnTaskFailure	ficelle	Nombre de nouvelles tentatives en cas d’échec de la tâche.
target	ficelle	Environnement dans lequel exécuter cette tâche.
timeoutInMinutes	ficelle	Durée maximale pendant laquelle la tâche peut s’exécuter avant d’être automatiquement annulée.

Conditions

Une tâche ne peut pas déterminer s’il faut poursuivre le travail de pipeline une fois la tâche terminée, fournir uniquement un état de fin tel que succeeded ou failed. Les tâches et travaux en aval peuvent ensuite définir un condition état basé sur cet état pour déterminer s’il faut s’exécuter.

La propriété conditions spécifie les conditions dans lesquelles cette tâche s’exécute. Par défaut, une étape s’exécute si rien dans son travail n’a pas encore échoué et que l’étape qui précède immédiatement sa fin.

Vous pouvez remplacer ou personnaliser ces valeurs par défaut en définissant l’étape à exécuter même si ou uniquement si une dépendance précédente échoue ou a un autre résultat. Vous pouvez également définir des conditions personnalisées, qui sont composées d’expressions.

Notes

Les conditions s’appliquent à toutes les dépendances directes et indirectes précédentes avec le même pool d’agents. Les étapes ou les travaux dans différents pools d’agents s’exécutent simultanément.

Les conditions basées sur l’état de dépendance précédent sont les suivantes :

• Réussite : Exécutez uniquement si toutes les dépendances précédentes réussissent. Ce comportement est la valeur par défaut si aucune condition n’est définie dans yaML. Pour appliquer cette condition, spécifiez condition: succeeded().
• Réussite ou échec : Exécuter même si une dépendance précédente échoue, sauf si l’exécution est annulée. Pour appliquer cette condition, spécifiez condition: succeededOrFailed().
• Toujours : Exécutez même si une dépendance précédente échoue, même si l’exécution est annulée. Pour appliquer cette condition, spécifiez condition: always().
• Échec : Exécuter uniquement lorsqu’une dépendance précédente échoue. Pour appliquer cette condition, spécifiez condition: failed().

Dans l’exemple YAML suivant, PublishTestResults@2 s’exécute même si l’étape précédente a échoué, en raison de sa condition succeededOrFailed .

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Continuer sur l’erreur

La continueOnError propriété indique à la tâche s’il faut continuer à exécuter et signaler la réussite indépendamment des échecs. Si la valeur est définie true, cette propriété indique à la tâche d’ignorer un failed état et de continuer à s’exécuter. Les étapes et les travaux en aval traitent le résultat de la tâche comme success lorsqu’ils prennent leurs décisions d’exécution.

activé

Par défaut, la tâche s’exécute chaque fois que le travail s’exécute. Vous pouvez définir enabled pour false désactiver la tâche. La désactivation temporaire de la tâche est utile pour supprimer la tâche du processus à des fins de test ou pour des déploiements spécifiques.

Nombre de nouvelles tentatives en cas d’échec de la tâche

La retryCountOnTaskFailure propriété spécifie le nombre de tentatives de la tâche en cas d’échec. La valeur par défaut est zéro nouvelle tentative.

• Le nombre maximal de nouvelles tentatives autorisées est de 10.
• Le temps d’attente avant la nouvelle tentative augmente après chaque tentative ayant échoué, en suivant une stratégie d’interruption exponentielle. La première nouvelle tentative se produit après 1 seconde, la deuxième nouvelle tentative après 4 secondes et la dixième tentative après 100 secondes.
• La nouvelle tentative de la tâche ne fournit pas d’idempotency. Les effets secondaires de la première tentative, comme la création partielle d’une ressource externe, peuvent entraîner l’échec des nouvelles tentatives.
• Aucune information sur le nombre de nouvelles tentatives n’est disponible pour la tâche.
• L’échec de la tâche ajoute un avertissement aux journaux des tâches indiquant qu’il a échoué avant de réessayer la tâche.
• Toutes les tentatives de nouvelle tentative s’affichent dans l’interface utilisateur dans le cadre du même nœud de tâche.

Notes

La retryCountOnTaskFailure propriété nécessite l’agent version 2.194.0 ou ultérieure. Sur Azure DevOps Server 2022, les nouvelles tentatives ne sont pas prises en charge pour les tâches sans agent. Pour plus d’informations, consultez la mise à jour du service Azure DevOps le 16 novembre 2021 - Nouvelles tentatives automatiques pour une tâche et la mise à jour du service Azure DevOps le 14 juin 2025 - Nouvelles tentatives pour les tâches serveur.

Cible

Les tâches s’exécutent dans un contexte d’exécution, qui correspond soit à l’hôte de l’agent, soit à un conteneur. Une tâche peut remplacer son contexte en spécifiant un target. Les options disponibles sont host de cibler l’hôte de l’agent et tous les conteneurs définis dans le pipeline. Dans l’exemple suivant, SampleTask@1 s’exécute sur l’hôte et AnotherTask@1 s’exécute dans un conteneur.

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Délai d'expiration

La période d’expiration commence lorsque la tâche démarre en cours d’exécution et n’inclut pas le moment où la tâche est mise en file d’attente ou attend un agent.

Notes

Les pipelines peuvent spécifier un délai d’expiration au niveau du travail en plus d’un délai d’expiration au niveau de la tâche. Si l’intervalle de délai d’expiration du niveau du travail s’écoule avant la fin d’une tâche, le travail en cours d’exécution se termine, même si la tâche est configurée avec un intervalle de délai d’expiration plus long. Pour plus d’informations, consultez la section sur les Délais d’expiration.

Classique

Dans les pipelines classiques, les tâches offrent plusieurs options de contrôle.

activé

Désactivez la case à cocher Activé pour désactiver une tâche. La désactivation temporaire de la tâche est utile pour supprimer la tâche du processus à des fins de test ou pour des déploiements spécifiques.

Conseil

Vous pouvez également cliquer avec le bouton droit sur la tâche dans le volet gauche, puis sélectionner Désactiver/Activer les tâches sélectionnées pour activer ce paramètre.

Continuer sur l’erreur

Sélectionnez cette option si vous souhaitez que cette tâche signale la réussite même si elle échoue, ce qui permet éventuellement à des tâches dépendantes dans le même travail d’être exécutées. La build ou le déploiement global ne peut pas être plus que partiellement réussi. Si les tâches suivantes s’exécutent dépendent également de leur paramètre Exécuter cette tâche .

Nombre de tentatives si la tâche a échoué

Spécifiez le nombre de nouvelles tentatives en cas d’échec de cette tâche. La valeur par défaut est zéro.

• La tâche défaillante est retentée en quelques secondes. Le temps d’attente avant la nouvelle tentative augmente après chaque tentative ayant échoué.
• La nouvelle tentative de la tâche ne fournit pas d’idempotency. Les effets secondaires de la première tentative, comme la création partielle d’une ressource externe, peuvent entraîner l’échec des nouvelles tentatives.
• Aucune information sur le nombre de nouvelles tentatives n’est disponible pour la tâche.
• L’échec de la tâche ajoute un avertissement aux journaux des tâches indiquant qu’il a échoué avant de réessayer la tâche.
• Toutes les tentatives de nouvelle tentative s’affichent dans l’interface utilisateur dans le cadre du même nœud de tâche.

Délai d'expiration

Entrez la durée maximale en minutes pendant laquelle la tâche peut s’exécuter avant d’être automatiquement annulée. La valeur par défaut est , ou l’heure 0infinie. La définition d’une valeur autre que zéro remplace le paramètre du travail de tâche parent. La période d’expiration commence lorsque la tâche démarre en cours d’exécution et n’inclut pas le moment où la tâche est mise en file d’attente ou attend un agent.

Exécuter cette tâche

Sélectionnez l’une des conditions suivantes pour exécuter cette tâche :

• Uniquement lorsque toutes les tâches précédentes ont réussi. Cette condition est la valeur par défaut.
• Même si une tâche précédente a échoué, sauf si la build a été annulée
• Même si une tâche précédente a échoué, même si la build a été annulée
• Uniquement lorsqu’une tâche précédente a échoué
• Conditions personnalisées, puis entrez une condition personnalisée spécifiant une expression pour laquelle cette tâche doit s’exécuter.

Notes

Si vous choisissez d’exécuter des tâches même lorsque la build est annulée, veillez à spécifier suffisamment de temps pour que ces tâches s’exécutent dans les options de délai d’attente.

Variables d'environnement

Vous pouvez utiliser des variables d’environnement pour mapper des informations système ou définies par l’utilisateur dans le processus de tâche.

YAML

Une tâche de pipeline YAML peut spécifier une env propriété, qui répertorie les chaînes nom/valeur qui représentent des variables d’environnement.

- task: AzureCLI@2
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

Vous pouvez définir des variables d’environnement à l’aide script d’étapes ou à l’aide de scripts dans la ligne de commande, Bash ou les tâches PowerShell.

L’exemple suivant exécute une script étape qui affecte une valeur à la ENV_VARIABLE_NAME variable d’environnement et renvoie la valeur.

- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

Le script précédent est fonctionnellement identique à l’exécution d’une tâche Bash@3 avec une script entrée. L’exemple suivant utilise la task syntaxe.

- task: Bash@3
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

Classique

Dans les pipelines classiques, vous pouvez ajouter et modifier des variables d’environnement dans la section Variables d’environnement de l’éditeur de tâches.

Tâches du programme d’installation de l’outil de génération

Les tâches du programme d’installation de l’outil de génération permettent à votre pipeline de build d’installer et de contrôler les dépendances. Vous pouvez utiliser les tâches du programme d’installation de l’outil de génération pour :

• Installez un outil ou un runtime pour une build, y compris sur des agents hébergés par Microsoft.
• Validez votre application ou bibliothèque par rapport à plusieurs versions d’une dépendance, comme Node.js.

Pour obtenir la liste des tâches d’installation d’outils, consultez Tâches d’outil.

Exemple : Tester et valider une application sur plusieurs versions de Node.js

L’exemple suivant configure un pipeline de build pour exécuter et valider une application sur plusieurs versions de Node.js.

YAML

Créez un fichier azure-pipelines.yml qui contient le contenu suivant dans le répertoire de base de votre projet.

pool:
  vmImage: 'windows-latest'

jobs:
- job: NodeJS
  strategy:
    matrix:
      node14:
        nodeVersion: '14.x'
      node16:
        nodeVersion: '16.x'
    maxParallel: 2
  steps:
    - task: NodeTool@0
      displayName: 'Install Node.js $(nodeVersion)'
      inputs:
        versionSpec: '$(nodeVersion)'
        checkLatest: true

    - script: |
        echo Using Node version $(nodeVersion)
        node --version
      displayName: 'Verify Node Installation'

Enregistrez et exécutez le pipeline. Le travail s’exécute deux fois, un pour chaque version de Node.js que vous avez spécifiée dans la nodeVersion variable.

Le programme d’installation de l’outil Node.js télécharge la version Node.js si elle n’est pas déjà sur l’agent. Le script de ligne de commande écrit la version installée dans la ligne de commande.

Classique

1. Dans le travail agent de votre pipeline Classique, sous plan d’exécution, définissez Parallelism sur Multi-configuration.

2. Sous Multiplicateurs, entrez nodeVersion.

3. Définissez le nombre maximal d’agents sur 2.

4. Ajoutez la tâche d’installation de l’outilNode.js à votre pipeline avec les paramètres suivants :

   • Entrez $(nodeVersion) sous Version Spec.
   • Activez la case à cocher pour vérifier la dernière version.

5. Ajoutez la tâche de ligne de commande à votre pipeline et entrez le code suivant sous Script :

   echo Using Node version $(nodeVersion)
node --version

6. Sous l’onglet Variables, définissez la variable nodeVersion avec la valeur 14.x, 16.x et sélectionnez Settable au moment de la file d’attente.

   Notes

   Dans un pipeline release, sélectionnez Settable au moment de la mise en production. Pour plus d’informations, consultez Comment puis-je modifier des variables au moment de la publication ?

7. Sélectionnez Enregistrer et mettre en file d’attente.

8. Dans l’écran Exécuter le pipeline , sélectionnez Enregistrer et exécuter.

Le travail s’exécute deux fois, un pour chaque version de Node.js que vous avez spécifiée dans la nodeVersion variable. La tâche du programme d’installation de l’outilNode.js télécharge la version Node.js si elle n’est pas déjà sur l’agent. La tâche Ligne de commande journalise l’emplacement de la version Node.js sur le disque.

Contenu connexe

• Tâches
• Groupes de tâches
• Informations de référence sur les tâches Azure Pipelines

Aide et support

• Consultez les conseils de dépannage.
• Obtenez des conseils sur Stack Overflow.
• Publiez vos questions, recherchez des réponses ou suggérez une fonctionnalité dans la Communauté des développeurs Azure DevOps.
• Obtenez un support pour Azure DevOps.