Partager via


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 également passer des propriétés à des phases, des étapes, et des tâches qui sont utilisées 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 inclure un nom et un type de données. Dans azure-pipelines.yml, si le paramètre yesNo est défini sur une valeur booléenne, la build réussit. Si yesNo la valeur est définie 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 d’autres propriétés à des étapes, 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, deploymentListou stageList .

templateContext facilite 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 créer des éléments YAML plus faciles à gérer et plus faciles à 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 }}:  # Iterate over each job in the 'testSet' parameter
  - ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}: # Check if the HTTP response is 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) }}: # Check if the HTTP response is 500
    - job:
      steps:
      - powershell: 'Get-ChildItem -Path Env:\' # Run a PowerShell script to list environment variables
      - ${{ testJob.steps }} # Include additional steps from the 'testJob' object
#azure-pipeline.yml

trigger: none

pool:
  vmImage: ubuntu-latest

extends:
  template: testing-template.yml 
  parameters:
    testSet:  # Define the 'testSet' parameter to pass to the template
    - job: positive_test # Define a job named 'positive_test'
      templateContext:
        expectedHTTPResponseCode: 200 # Set the expected HTTP response code to 200 for this job
      steps:
      - script: echo "Run positive test" 
    - job: negative_test # Define a job named 'negative_test'
      templateContext:
        expectedHTTPResponseCode: 500 # Set the expected HTTP response code to 500 for this job
      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) }}: # Check if 'experimentalTemplate' is true
  - template: experimental.yml
- ${{ if not(eq(parameters.experimentalTemplate, true)) }}:  # Check if 'experimentalTemplate' is not true
  - template: stable.yml

Types de données de paramètre

Type de données Remarques
string chaîne
stringList une liste d’éléments, plusieurs peuvent être sélectionnés. Non disponible dans les modèles
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 une seule tâche de déploiement
deploymentList séquence de travaux de déploiement
stage une seule phase
stageList séquence d'étapes

Les types de données step, stepList, job, jobList, deployment, deploymentList, stage, stringList et stageList utilisent tous le format de schéma YAML standard. Cet exemple inclut string, , numberboolean, object, stepet stepList.

Remarque

Le stringList type de données n’est pas disponible dans les modèles. Utilisez plutôt le object type de données dans les modèles.

parameters:
- name: myString  # Define a parameter named 'myString'
  type: string  # The parameter type is string
  default: a string  # Default value is 'a string'

- name: myMultiString  # Define a parameter named 'myMultiString'
  type: string  # The parameter type is string
  default: default  # Default value is 'default', only one default
  values:  # Allowed values for 'myMultiString'
  - default  
  - ubuntu  

- name: myStringlist # Define a parameter named 'myStringlist'
  type: stringList # The parameter type is stringList
  displayName: Regions
  values: # Allowed values for 'myStringlist'
    - WUS
    - CUS
    - EUS
  default: # Default values
    - WUS
    - CUS
    
- name: myNumber  # Define a parameter named 'myNumber'
  type: number  # The parameter type is number
  default: 2  # Default value is 2
  values:  # Allowed values for 'myNumber'
  - 1  
  - 2  
  - 4  
  - 8  
  - 16  

- name: myBoolean  # Define a parameter named 'myBoolean'
  type: boolean  # The parameter type is boolean
  default: true  # Default value is true

- name: myObject  # Define a parameter named 'myObject'
  type: object  # The parameter type is object
  default:  # Default value is an object with nested properties
    foo: FOO  # Property 'foo' with value 'FOO'
    bar: BAR  # Property 'bar' with value 'BAR'
    things:  # Property 'things' is a list
    - one  
    - two  
    - three  
    nested:  # Property 'nested' is an object
      one: apple  # Property 'one' with value 'apple'
      two: pear  # Property 'two' with value 'pear'
      count: 3  # Property 'count' with value 3

- name: myStep  # Define a parameter named 'myStep'
  type: step  # The parameter type is step
  default:  # Default value is a step
    script: echo my step 

- name: mySteplist  # Define a parameter named 'mySteplist'
  type: stepList  # The parameter type is stepList
  default:  # Default value is a list of steps
    - script: echo step one  
    - script: echo step two  
    
trigger: none  

jobs: 
- job: stepList  # Define a job named 'stepList'
  steps: ${{ parameters.mySteplist }}  # Use the steps from the 'mySteplist' parameter

- job: myStep  # Define a job named 'myStep'
  steps:
    - ${{ parameters.myStep }}  # Use the step from the 'myStep' parameter

- job: stringList  # Define a job named 'stringList'
  steps:
  - ${{ each region in parameters.myStringlist }}:
      - script: echo ${{region}}

Itération via les paramètres et leurs types de données

Azure Pipelines vous permet d’effectuer une itération via des paramètres de différents types de données, tels que des chaînes, des objets, des nombres et des booléens. Cette flexibilité permet un comportement de pipeline dynamique en fonction des valeurs de paramètre. Vous trouverez ci-dessous des exemples illustrant comment effectuer une itération via des paramètres et gérer différents types de données.

Itération via des paramètres simples

Vous pouvez parcourir des paramètres simples tels que des chaînes, des nombres et des booléens. Dans cet exemple, le pipeline effectue une itération dans une liste de paramètres et imprime leurs noms et valeurs.

# start.yaml
parameters:
- name: myStringName
  type: string
  default: a string value
- name: myNumber
  type: number
  default: 2
- 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

Itération dans les objets

Les objets vous permettent de définir des structures de paramètres complexes, telles que des éléments imbriqués. Vous pouvez effectuer une itération via des objets pour accéder à leurs clés et valeurs ou propriétés imbriquées.

Exemple : Itération par le biais de clés et de valeurs d’objet

Le fichier de modèle suivant définit le myObject paramètre en tant qu’objet avec des paires clé-valeur par défaut. Le travail effectue une itération dans les clés et imprime leurs valeurs.

# object-keys-template.yml

parameters:
  - name: myObject
    type: object
    default:
      key1: 'value1'
      key2: 'value2'
      key3: 'value3'

jobs:
- job: ExampleJob
  displayName: 'Example object parameter job'
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: |
      echo "Keys in myObject:"
      echo "Key1: ${{ parameters.myObject.key1 }}"
      echo "Key2: ${{ parameters.myObject.key2 }}"
      echo "Key3: ${{ parameters.myObject.key3 }}"
    displayName: 'Display object keys and values'

Le pipeline remplace les valeurs par défaut des myObject valeurs personnalisées.

# azure-pipelines.yml

trigger:
- main

extends:
  template: object-keys-template.yml
  parameters:
    myObject:
      key1: 'customValue1'
      key2: 'customValue2'
      key3: 'customValue3'
Exemple : Itération via des objets imbriqués

Le modèle définit un listOfFruits paramètre contenant des objets avec des tableaux imbriqués, puis utilise des boucles imbriquées pour traiter chaque fruit et ses couleurs associées.

# File: nested-objects-template.yml

parameters:
- name: listOfFruits
  type: object
  default:
  - fruitName: 'apple'
    colors: ['red', 'green']
  - fruitName: 'lemon'
    colors: ['yellow']

steps:
- ${{ each fruit in parameters.listOfFruits }}: # Iterate over each fruit in the 'listOfFruits'
  - ${{ each fruitColor in fruit.colors }}: # Iterate over each color in the current fruit's colors
    - script: echo ${{ fruit.fruitName }} ${{ fruitColor }} # Echo the current fruit's name and color

Le fichier de pipeline montre comment remplacer les valeurs par défaut par des données de fruits personnalisées.

# File: azure-pipelines.yml

trigger:
- main

extends:
  template: nested-objects-template.yml
  parameters:
    listOfFruits:
    - fruitName: 'banana'
      colors: ['yellow']
    - fruitName: 'grape'
      colors: ['purple', 'green']

Inclure dynamiquement une liste d’étapes avec le paramètre stepList

Dans cet exemple, le type de paramètre stepList est utilisé pour inclure dynamiquement une liste d’étapes dans le processus de génération.

  • Le pipeline principal (azure-pipelines.yml) définit deux travaux : générer et déployer.
  • Le travail de génération utilise un modèle (build.yml) et transmet une liste de tâches de génération à l’aide du paramètres stepList.
  • Le modèle build.yml inclut dynamiquement les étapes définies dans le paramètre build_tasks.
#azure-pipelines.yml

trigger:
- main

jobs:
  - job: build
    displayName: 'Build .NET Core Application'
    pool:
      vmImage: 'ubuntu-latest'

    steps:
      - checkout: self

      - template: build.yml
        parameters:
          build_tasks:
            - task: DotNetCoreCLI@2
              displayName: 'Restore'
              inputs:
                command: 'restore'
                projects: '**/*.csproj'  

            - task: DotNetCoreCLI@2
              displayName: 'Build'
              inputs:
                command: 'build'
                arguments: '--no-restore'
                projects: '**/*.csproj' 

  - job: deploy
    displayName: 'Pack for Azure App Service deployment'
    dependsOn: build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - download: current
        artifact: drop

Le modèle build.yml :

  • Définit le paramètre build_tasks avec le type stepList et une liste vide par défaut.
  • Définit le Kit de développement logiciel (SDK) .NET Core sur 8.x.
  • Itère chaque étape dans le paramètre build_tasks.
  • Exécute chaque étape définie dans la liste build_tasks.
#build.yml

parameters:
  - name: build_tasks
    type: stepList
    default: []

steps:
  - task: UseDotNet@2
    displayName: 'Use .NET Core SDK'
    inputs:
      packageType: 'sdk'
      version: '8.x'

  - ${{ each step in parameters.build_tasks }}:
      - ${{ step }}

  - task: DotNetCoreCLI@2
    displayName: 'Publish'
    inputs:
      command: 'publish'
      arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
      projects: '**/*.csproj'

  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifact'
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
      ArtifactName: 'drop'