Paramètres de runtime
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
Les paramètres de runtime vous permettent d’avoir plus de contrôle sur les valeurs qui peuvent être passées à un pipeline. Avec des paramètres de runtime, vous pouvez :
- Fournir des valeurs différentes aux scripts et aux tâches au moment de l’exécution
- Types de paramètres de contrôle, plages autorisées et valeurs par défaut
- Sélectionner dynamiquement des travaux et des étapes avec des expressions de modèle
Vous pouvez spécifier des paramètres dans des modèles et dans le pipeline. Les paramètres ont des types de données comme des nombres et des chaînes et ils peuvent être limités à un sous-ensemble de valeurs. La section parameters
dans un fichier YAML définit les paramètres disponibles.
Les paramètres sont uniquement disponibles au moment de l’analyse des modèles. Les paramètres sont développés juste avant les exécutions de pipeline afin que les valeurs entourées par ${{ }}
soient remplacées par des valeurs de paramètre. Utilisez des variables si vous avez besoin que vos valeurs soient plus largement disponibles pendant votre exécution de pipeline.
Notes
Ces conseils ne s’appliquent pas aux pipelines classiques. Pour connaître les paramètres dans les pipelines classiques, consultez Paramètres de processus (classique).
Les paramètres doivent contenir un nom et un type de données. Les paramètres ne peuvent pas être facultatifs. Une valeur par défaut doit être affectée dans votre fichier YAML ou lorsque vous exécutez votre pipeline. Si vous n’affectez pas de valeur par défaut ou si vous ne définissez pas default
sur false
, la première valeur disponible est utilisée.
Utilisez templateContext pour passer des propriétés supplémentaires à des index, des étapes et des travaux qui sont utilisés comme paramètres dans un modèle.
Utiliser des paramètres dans les pipelines
Définissez les paramètres de runtime au début d’un fichier YAML.
Cet exemple de pipeline inclut un paramètre image
avec trois agents hébergés en tant qu’options string
. Dans la section des travaux, la valeur pool
spécifie l’agent à partir du paramètre utilisé pour exécuter le travail. trigger
est défini sur « none » afin que vous puissiez sélectionner la valeur de image
lorsque vous déclenchez manuellement l’exécution de votre pipeline.
parameters:
- name: image
displayName: Pool Image
type: string
default: ubuntu-latest
values:
- windows-latest
- ubuntu-latest
- macOS-latest
trigger: none
jobs:
- job: build
displayName: build
pool:
vmImage: ${{ parameters.image }}
steps:
- script: echo building $(Build.BuildNumber) with ${{ parameters.image }}
Lorsque le pipeline s’exécute, vous sélectionnez l’image du pool. Si vous n’effectuez pas de sélection, l’option par défaut ubuntu-latest
est utilisée.
Utiliser des conditions avec des paramètres
Vous pouvez également utiliser des paramètres dans le cadre de la logique conditionnelle. Avec des conditions, une partie d’un fichier YAML s’exécute si elle répond aux critères if
.
Utiliser des paramètres pour déterminer les étapes qui s’exécutent
Ce pipeline ajoute un deuxième paramètre booléen, test
, qui peut être utilisé pour déterminer si des tests sont exécutés ou non dans le pipeline. Lorsque la valeur de test
est true, l’étape qui génère l’exécution de tous les tests s’exécute.
parameters:
- name: image
displayName: Pool Image
values:
- windows-latest
- ubuntu-latest
- macOS-latest
- name: test
displayName: Run Tests?
type: boolean
default: false
trigger: none
jobs:
- job: build
displayName: Build and Test
pool:
vmImage: ${{ parameters.image }}
steps:
- script: echo building $(Build.BuildNumber)
- ${{ if eq(parameters.test, true) }}:
- script: echo "Running all the tests"
Utiliser des paramètres pour définir la configuration utilisée
Vous pouvez également utiliser des paramètres pour définir le travail qui s’exécute. Dans cet exemple, différentes architectures sont générées en fonction de la valeur du paramètre config
, qui est un type string
. Par défaut, les architectures x86
et x64
sont générées.
parameters:
- name: configs
type: string
default: 'x86,x64'
trigger: none
jobs:
- ${{ if contains(parameters.configs, 'x86') }}:
- job: x86
steps:
- script: echo Building x86...
- ${{ if contains(parameters.configs, 'x64') }}:
- job: x64
steps:
- script: echo Building x64...
- ${{ if contains(parameters.configs, 'arm') }}:
- job: arm
steps:
- script: echo Building arm...
Exclure un index de manière sélective
Vous pouvez également utiliser des paramètres pour déterminer si un index s’exécute. Dans cet exemple, il existe un pipeline avec quatre index et des travaux différents pour chaque index. L’index Test de performances s’exécute si le paramètre runPerfTests
a la valeur true. La valeur par défaut de runPerfTests
est false. Par conséquent, sans aucune mise à jour, seuls trois des quatre index s’exécutent.
parameters:
- name: runPerfTests
type: boolean
default: false
trigger: none
stages:
- stage: Build
displayName: Build
jobs:
- job: Build
steps:
- script: echo running Build
- stage: UnitTest
displayName: Unit Test
dependsOn: Build
jobs:
- job: UnitTest
steps:
- script: echo running UnitTest
- ${{ if eq(parameters.runPerfTests, true) }}:
- stage: PerfTest
displayName: Performance Test
dependsOn: Build
jobs:
- job: PerfTest
steps:
- script: echo running PerfTest
- stage: Deploy
displayName: Deploy
dependsOn: UnitTest
jobs:
- job: Deploy
steps:
- script: echo running UnitTest
Exécuter en boucle des paramètres
Vous pouvez également exécuter en boucle vos paramètres de chaîne, de nombre et booléens.
Dans cet exemple, vous exécutez en boucle des paramètres et imprimez le nom et la valeur de chaque paramètre. Il existe quatre paramètres différents et chacun représente un type différent. myStringName
est une chaîne à une seule ligne. myMultiString
est une chaîne à plusieurs lignes. myNumber
is a number. myBoolean
est une valeur booléenne. Dans la section des étapes, les tâches de script génèrent la clé et la valeur de chaque paramètre.
# start.yaml
parameters:
- name: myStringName
type: string
default: a string value
- name: myMultiString
type: string
default: default
values:
- default
- ubuntu
- name: myNumber
type: number
default: 2
values:
- 1
- 2
- 4
- 8
- 16
- name: myBoolean
type: boolean
default: true
steps:
- ${{ each parameter in parameters }}:
- script: echo ${{ parameter.Key }}
- script: echo ${{ parameter.Value }}
# azure-pipeline.yaml
trigger: none
extends:
template: start.yaml
Rechercher un objet de paramètre vide
Vous pouvez utiliser l’expression length()
pour vérifier si un paramètre d’objet n’a aucune valeur.
parameters:
- name: foo
type: object
default: []
steps:
- checkout: none
- ${{ if eq(length(parameters.foo), 0) }}:
- script: echo Foo is empty
displayName: Foo is empty
Types de données de paramètre
Type de données | Notes |
---|---|
string |
string |
number |
peut être limité à values: , sinon toute chaîne de type nombre est acceptée |
boolean |
true ou false |
object |
toute structure YAML |
step |
une seule étape |
stepList |
Séquence d’étapes |
job |
un seul travail |
jobList |
Séquence de travaux |
deployment |
un seul travail de déploiement |
deploymentList |
séquence de travaux de déploiement |
stage |
une seule phase |
stageList |
séquence d’index |
Les types de données step, stepList, job, jobList, deploymentList, stagelist et stageList utilisent tous le format de schéma YAML standard. Cet exemple inclut string, number, boolean, object, step et stepList.
parameters:
- name: myString
type: string
default: a string
- name: myMultiString
type: string
default: default
values:
- default
- ubuntu
- name: myNumber
type: number
default: 2
values:
- 1
- 2
- 4
- 8
- 16
- name: myBoolean
type: boolean
default: true
- name: myObject
type: object
default:
foo: FOO
bar: BAR
things:
- one
- two
- three
nested:
one: apple
two: pear
count: 3
- name: myStep
type: step
default:
script: echo my step
- name: mySteplist
type: stepList
default:
- script: echo step one
- script: echo step two
trigger: none
jobs:
- job: stepList
steps: ${{ parameters.mySteplist }}
- job: myStep
steps:
- ${{ parameters.myStep }}
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