Partager via

types de tâches et utilisation

  • Article

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

Une tâche exécute une action dans un pipeline et est une procédure ou un script packagé qui a été extraite avec un ensemble d’entrées. Les tâches sont les blocs de construction pour définir l’automatisation dans un pipeline.

Lorsque vous exécutez un travail, toutes les tâches sont exécutées dans l’ordre, l’une après l’autre. Pour exécuter le même ensemble de tâches en parallèle sur plusieurs agents, ou pour exécuter certaines tâches sans utiliser d’agent, consultez les travaux.

Par défaut, toutes les tâches s’exécutent dans le même contexte, que ce soit sur l’hôte ou dans un conteneur de travaux.

Vous pouvez éventuellement utiliser des phases cibles pour contrôler le contexte d’une tâche individuelle.

Découvrez-en plus sur la façon de spécifier les propriétés d’une tâche avec les tâches intégrées.

Lorsque vous exécutez un travail, toutes les tâches sont exécutées dans l’ordre, l’une après l’autre, sur un agent. Pour exécuter le même ensemble de tâches en parallèle sur plusieurs agents, ou pour exécuter certaines tâches sans utiliser d’agent, consultez les travaux.

Pour en savoir plus sur les attributs généraux pris en charge par les tâches, consultez la référence YAML pour les steps.task.

Tâches personnalisées

Azure DevOps inclut des tâches intégrées pour activer des scénarios de création et de déploiement fondamentaux. Vous pouvez également créer vos propres tâches personnalisées.

En outre, Visual Studio Marketplace propose de nombreuses extensions ; chacune d’entre elles, lorsqu’elle est installée sur votre abonnement ou votre collection, étend le catalogue de tâches d’une ou de plusieurs tâches. Vous pouvez également écrire vos propres extensions personnalisées pour ajouter des tâches à Azure Pipelines.

Dans les pipelines YAML, vous faites référence aux tâches par leur nom. Si un nom correspond à la fois à une tâche prédéfinie et à une tâche personnalisée, la première est prioritaire. Vous pouvez utiliser le GUID d’une tâche ou un nom complet pour une tâche personnalisée afin d’éviter ce risque :

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Pour rechercher myPublisherId et myExtensionId, sélectionnez Obtenir sur une tâche dans la marketplace. Les valeurs après itemName dans votre chaîne d’URL sont myPublisherId et myExtensionId. Vous pouvez également trouver le nom complet en ajoutant la tâche à un pipeline de mise en production et en sélectionnant Afficher YAML lors de la modification de la tâche.

Versions des tâches

Les tâches sont versionnées et vous devez spécifier la version principale de la tâche utilisée dans votre pipeline. Cette pratique permet d’éviter les problèmes lors de la mise en production de nouvelles versions d’une tâche. Les tâches sont généralement rétrocompatibles, mais dans certains scénarios, vous pouvez rencontrer des erreurs imprévisibles lorsqu’une tâche est automatiquement mise à jour.

Lorsqu’une nouvelle version mineure est mise en production (par exemple, 1.2 vers 1.3), votre pipeline utilise automatiquement la nouvelle version. Toutefois, si une nouvelle version principale est mise en production (par exemple, 2.0), votre pipeline continue d’utiliser la version principale que vous avez spécifiée tant que vous ne modifiez pas le pipeline et ne basculez pas manuellement vers la nouvelle version principale. Le journal inclut une alerte indiquant qu’une nouvelle version principale est disponible.

Vous pouvez définir la version mineure utilisée en spécifiant le numéro de version complet d’une tâche après le signe @ (exemple : GoTool@0.3.1). Vous pouvez uniquement utiliser des versions des tâches qui existent pour votre organisation.

Dans un fichier YAML, vous spécifiez la version principale en utilisant @ dans le nom de la tâche. Par exemple, pour épingler à la version 2 de la tâche PublishTestResults :

steps:
- task: PublishTestResults@2

Les pipelines YAML ne sont pas disponibles dans TFS.

Options de contrôle de la tâche

Chaque tâche vous offre des options de contrôle.

Les options de contrôle sont disponibles sous forme de clés dans la section task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Les options de contrôle sont disponibles sous forme de clés dans la section task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Les options de contrôle sont disponibles sous forme de clés dans la section task.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Notes

Une tâche donnée ou un travail donné ne peuvent pas déterminer unilatéralement si le travail/l’index continue. En revanche, ils peuvent proposer un état de réussite ou d’échec. Ainsi, les tâches/travaux en aval ont tous un calcul de condition qui leur permet de déterminer s’ils doivent s’exécuter ou non. La condition par défaut stipule effectivement de « s’exécuter si l’état est celui de réussite ».

Le paramètre Continuer en cas d’erreur modifie ce comportement d’une manière subtile. Il « incite » toutes les étapes/tous les travaux en aval à traiter tout résultat comme une « réussite » dans le but de prendre cette décision. Autrement dit, il invite à « ne pas tenir compte de l’échec de cette tâche pour prendre une décision sur la condition de la structure contenante ».

Le délai d’expiration commence au démarrage de l’exécution de la tâche. Il n’inclut pas le temps de mise en file d’attente de la tâche ni le temps d’attente d’un agent.

Remarque

Les pipelines peuvent avoir un délai d’expiration au niveau du travail spécifié en plus d’un délai d’expiration au niveau de la tâche. Si le délai d’expiration au niveau du travail s’écoule avant que l’étape ne soit terminée, le projet en cours est interrompu, même si l’étape est configurée avec un délai d’attente plus long. Pour plus d’informations, consultez la section sur les Délais d’expiration.

Dans ce YAML, PublishTestResults@2 s’exécute même si l’étape précédente échoue à cause de la condition succeededOrFailed().

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

Conditions

  • Uniquement lorsque toutes les dépendances directes et indirectes précédentes avec le même pool d'agents réussissent. Si vous disposez de différents pools d'agents, ces étapes ou travaux s'exécutent simultanément. Cette condition est la condition par défaut si aucune condition n'est définie dans le YAML.

  • Même si une dépendance précédente échoue, à moins que l'exécution ne soit annulée. Utilisez succeededOrFailed() dans le fichier YAML pour cette condition.

  • Même si une dépendance précédente échoue, et même si l'exécution est annulée. Utilisez always() dans le fichier YAML pour cette condition.

  • Uniquement en cas d'échec d'une dépendance précédente. Utilisez failed() dans le fichier YAML pour cette condition.

Cible d’étape

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 étape individuelle peut remplacer son contexte en spécifiant un target. Les options disponibles sont le mot host pour cibler l’hôte de l’agent ainsi que tous les conteneurs définis dans le pipeline. Par exemple :

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

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

Ici, SampleTask s’exécute sur l’hôte et AnotherTask s’exécute dans un conteneur.

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

Utilisez retryCountOnTaskFailure pour spécifier le nombre de nouvelles tentatives en cas d’échec de la tâche. La valeur par défaut est zéro nouvelle tentative. Pour plus d’informations sur les propriétés de tâche, consultez steps.task dans le schéma YAML.

- task: <name of task>
  retryCountOnTaskFailure: <max number of retries>
   ...

Remarque

  • Nécessite la version 2.194.0 ou ultérieure de l’agent. 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 Mise à jour du service Azure DevOps du 16 novembre 2021 - Nouvelles tentatives automatiques pour une tâche et Mise à jour du service Azure DevOps du 14 juin 2025 - Nouvelles tentatives pour les tâches serveur.
  • Le temps d’attente entre chaque nouvelle tentative augmente après chaque tentative ayant échoué. La première nouvelle tentative est effectuée en quelques secondes.
  • Il n’existe aucune hypothèse concernant l’idempotence de la tâche. Si la tâche a des effets secondaires (par exemple, si elle a partiellement créé une ressource externe), alors elle peut échouer lors de sa deuxième exécution.
  • Il n’existe aucune information sur le nombre de nouvelles tentatives disponibles pour la tâche.
  • Un avertissement est ajouté aux journaux des tâches pour indiquer qu’elle a échoué avant d’être retentée.
  • Toutes les nouvelles tentatives d’exécution d’une tâche figurent dans l’interface utilisateur dans le cadre du même nœud de tâche.

Les pipelines YAML ne sont pas disponibles dans TFS.

Variables d'environnement

Chaque tâche a une propriété env qui correspond à la liste des paires de chaînes qui représentent des variables d’environnement mappées dans le processus de la tâche.

- task: AzureCLI@2
  displayName: Azure CLI
  inputs: # Specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

L’exemple suivant exécute l’étape script, qui est correspond à un raccourci pour la tâche de ligne de commande, suivie de la syntaxe de la tâche équivalente. Cet exemple affecte une valeur à la variable d’environnement AZURE_DEVOPS_EXT_PAT, qui est utilisée pour l’authentification auprès de l’interface CLI Azure DevOps.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'


- task: Bash@3
  inputs:
     targetType: # specific to each task
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

L'exemple suivant exécute l'étape script, qui est un raccourci pour l'étape Bash@3, suivie de la syntaxe de la tâche équivalente. Cet exemple attribue une valeur à la variable d'environnement ENV_VARIABLE_NAME et la répercute.

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

Programmes d’installation d’outils de génération (Azure Pipelines)

Les programmes d’installation d’outils permettent à votre pipeline de build d’installer et de contrôler vos dépendances. Plus précisément, vous pouvez :

  • Installez un outil ou un runtime à la volée (même sur des agents hébergés par Microsoft) juste à temps pour votre build CI.

  • Validez votre application ou bibliothèque par rapport à plusieurs versions d’une dépendance, comme Node.js.

Par exemple, vous pouvez configurer votre pipeline de build pour exécuter et valider votre application pour plusieurs versions de Node.js.

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

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

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Créez un pipeline de build et exécutez-le. Observez comment la build est exécutée. 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 journalise l’emplacement de la version Node.js sur le disque.

Les pipelines YAML ne sont pas disponibles dans TFS.

Tâche du programme d’installation de l’outil

Pour obtenir la liste des tâches de notre programme d’installation de l’outil, consultez Tâches du programme d’installation de l’outil.

Désactivation des tâches prédéfinies et de la marketplace

Dans la page des paramètres de l’organisation, vous pouvez désactiver les tâches de la marketplace, les tâches prédéfinies ou les deux. La désactivation des tâches de la marketplace peut contribuer à renforcer la sécurité de vos pipelines. Si vous désactivez à la fois les tâches prédéfinies et les tâches Marketplace, seules les tâches que vous installez avec tfx sont disponibles.

Aide et support