Paramètres de modèle
Vous pouvez spécifier des paramètres et leurs types de données dans un modèle et référencer ces paramètres dans un pipeline. Avec templateContext, vous pouvez 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.
Vous pouvez également utiliser des paramètres en dehors des modèles. Vous pouvez uniquement utiliser des littéraux pour les valeurs par défaut des paramètres. Consultez la section sur les paramètres dans le schéma YAML.
Passage de paramètres
Les paramètres doivent contenir un nom et un type de données. Dans azure-pipelines.yml
, lorsque le paramètre yesNo
est défini sur une valeur booléenne, la build réussit. Quand yesNo
est défini sur une chaîne telle que apples
, la build échoue.
# File: simple-param.yml
parameters:
- name: yesNo # name of the parameter; required
type: boolean # data type of the parameter; required
default: false
steps:
- script: echo ${{ parameters.yesNo }}
# File: azure-pipelines.yml
trigger:
- main
extends:
template: simple-param.yml
parameters:
yesNo: false # set to a non-boolean value to have the build fail
Utiliser templateContext pour passer des propriétés aux modèles
Vous pouvez utiliser templateContext
pour passer des propriétés supplémentaires à des phases, des étapes et des travaux utilisés comme paramètres dans un modèle. Plus précisément, vous pouvez spécifier templateContext
dans le type de données de paramètre jobList
, deploymentList
ou stageList
.
Vous pouvez utiliser templateContext
pour faciliter la configuration des environnements lors du traitement de chaque travail. En regroupant un travail et son objet de propriétés d’environnement, templateContext
vous pouvez avoir un YAML plus facile à gérer et à comprendre.
Dans cet exemple, le paramètre testSet
dans testing-template.yml
a le type de données jobList
. Le modèle testing-template.yml
crée une variable testJob
à l’aide de chaque mot clé. Le modèle référence ensuite le testJob.templateContext.expectedHTTPResponseCode
, qui est défini dans azure-pipeline.yml
et passé au modèle.
Lorsque le code de réponse est 200, le modèle effectue une requête REST. Lorsque le code de réponse est 500, le modèle génère toutes les variables d’environnement pour le débogage.
templateContext
peut contenir des propriétés.
#testing-template.yml
parameters:
- name: testSet
type: jobList
jobs:
- ${{ each testJob in parameters.testSet }}:
- ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
- job:
steps:
- powershell: 'Invoke-RestMethod -Uri https://blogs.msdn.microsoft.com/powershell/feed/ | Format-Table -Property Title, pubDate'
- ${{ testJob.steps }}
- ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
- job:
steps:
- powershell: 'Get-ChildItem -Path Env:\'
- ${{ testJob.steps }}
#azure-pipeline.yml
trigger: none
pool:
vmImage: ubuntu-latest
extends:
template: testing-template.yml
parameters:
testSet:
- job: positive_test
templateContext:
expectedHTTPResponseCode: 200
steps:
- script: echo "Run positive test"
- job: negative_test
templateContext:
expectedHTTPResponseCode: 500
steps:
- script: echo "Run negative test"
Paramètres pour sélectionner un modèle au moment de l’exécution
Vous pouvez appeler différents modèles à partir d’un pipeline YAML en fonction d’une condition. Dans cet exemple, l’élément YAML experimental.yml
s’exécute lorsque le paramètre experimentalTemplate
a la valeur true.
#azure-pipeline.yml
parameters:
- name: experimentalTemplate
displayName: 'Use experimental build process?'
type: boolean
default: false
steps:
- ${{ if eq(parameters.experimentalTemplate, true) }}:
- template: experimental.yml
- ${{ if not(eq(parameters.experimentalTemplate, true)) }}:
- template: stable.yml
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 }}
Vous pouvez itérer au sein d’un objet et imprimer chaque chaîne de l’objet.
parameters:
- name: listOfStrings
type: object
default:
- one
- two
steps:
- ${{ each value in parameters.listOfStrings }}:
- script: echo ${{ value }}
En outre, vous pouvez itérer au sein d’un objet à travers des éléments imbriqués.
parameters:
- name: listOfFruits
type: object
default:
- fruitName: 'apple'
colors: ['red','green']
- fruitName: 'lemon'
colors: ['yellow']
steps:
- ${{ each fruit in parameters.listOfFruits }} :
- ${{ each fruitColor in fruit.colors}} :
- script: echo ${{ fruit.fruitName}} ${{ fruitColor }}
Paramètres obligatoires
Vous pouvez ajouter une étape de validation au début de votre modèle pour vérifier les paramètres dont vous avez besoin.
Voici un exemple qui recherche le paramètre à l’aide solution
de Bash (ce qui lui permet de fonctionner sur n’importe quelle plateforme) :
# File: steps/msbuild.yml
parameters:
- name: 'solution'
default: ''
type: string
steps:
- bash: |
if [ -z "$SOLUTION" ]; then
echo "##vso[task.logissue type=error;]Missing template parameter \"solution\""
echo "##vso[task.complete result=Failed;]"
fi
env:
SOLUTION: ${{ parameters.solution }}
displayName: Check for required parameters
- task: msbuild@1
inputs:
solution: ${{ parameters.solution }}
- task: vstest@2
inputs:
solution: ${{ parameters.solution }}
Pour montrer que le modèle échoue s’il manque le paramètre requis :
# File: azure-pipelines.yml
# This will fail since it doesn't set the "solution" parameter to anything,
# so the template will use its default of an empty string
steps:
- template: steps/msbuild.yml
Vous pouvez passer des paramètres aux modèles.
La parameters
section définit les paramètres disponibles dans le modèle et leurs valeurs par défaut.
Les modèles sont développés juste avant l’exécution du pipeline afin que les valeurs entourées par ${{ }}
soient remplacées par les paramètres qu’il reçoit du pipeline englobant. Par conséquent, seules les variables prédéfinies peuvent être utilisées dans les paramètres.
Pour utiliser des paramètres dans plusieurs pipelines, découvrez comment créer un groupe de variables.
Modèles de travail, de phase et d’étape avec des paramètres
# File: templates/npm-with-params.yml
parameters:
name: '' # defaults for any parameters that aren't specified
vmImage: ''
jobs:
- job: ${{ parameters.name }}
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
Lorsque vous utilisez le modèle dans votre pipeline, spécifiez des valeurs pour les paramètres du modèle.
# File: azure-pipelines.yml
jobs:
- template: templates/npm-with-params.yml # Template reference
parameters:
name: Linux
vmImage: 'ubuntu-latest'
- template: templates/npm-with-params.yml # Template reference
parameters:
name: macOS
vmImage: 'macOS-10.13'
- template: templates/npm-with-params.yml # Template reference
parameters:
name: Windows
vmImage: 'windows-latest'
Vous pouvez également utiliser des paramètres avec des modèles d’étape ou de phase. Par exemple, les étapes avec les paramètres :
# File: templates/steps-with-params.yml
parameters:
runExtendedTests: 'false' # defaults for any parameters that aren't specified
steps:
- script: npm test
- ${{ if eq(parameters.runExtendedTests, 'true') }}:
- script: npm test --extended
Lorsque vous utilisez le modèle dans votre pipeline, spécifiez des valeurs pour les paramètres du modèle.
# File: azure-pipelines.yml
steps:
- script: npm install
- template: templates/steps-with-params.yml # Template reference
parameters:
runExtendedTests: 'true'
Notes
Les paramètres scalaires sont toujours traités comme des chaînes.
Par exemple, eq(parameters['myparam'], true)
retourne true
presque toujours , même si le myparam
paramètre est le mot false
.
Les chaînes non vides sont converties en true
dans un contexte booléen.
Cette expression peut être réécrite pour comparer explicitement les chaînes : eq(parameters['myparam'], 'true')
.
Les paramètres ne sont pas limités aux chaînes scalaires. Tant que l’endroit où le paramètre se développe attend un mappage, le paramètre peut être un mappage. De même, les séquences peuvent être passées là où des séquences sont attendues. Par exemple :
# azure-pipelines.yml
jobs:
- template: process.yml
parameters:
pool: # this parameter is called `pool`
vmImage: ubuntu-latest # and it's a mapping rather than a string
# process.yml
parameters:
pool: {}
jobs:
- job: build
pool: ${{ parameters.pool }}
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de l’année 2024, nous abandonnerons progressivement le mécanisme de retour d’information GitHub Issues pour le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez :Soumettre et afficher des commentaires pour