types de tâches et utilisation
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.
retryCountOnTaskFailure: string # Number of retries if the task fails.
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.
- Conditions personnalisées, qui sont composées d’expressions
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. 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. Non pris en charge pour les tâches sans agent.
- La tâche défaillante est retentée en quelques secondes. Le temps d’attente entre chaque nouvelle tentative augmente après chaque tentative ayant échoué.
- 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.
Articles connexes
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.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour