Partager via


Paramètres de runtime

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

Les paramètres d’exécution vous donnent davantage de contrôle sur les valeurs que vous passez à un pipeline. Avec les paramètres d’exécution, 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élection dynamique de travaux et d’étapes à l’aide d’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 disponibles uniquement pendant l’analyse de modèle. Ils s’étendent avant l’exécution du pipeline, en remplaçant les valeurs entourées de ${{ }} par les valeurs de paramètre. Utilisez des variables si vos valeurs doivent être disponibles tout au long de l’exécution du pipeline.

Notes

Cette aide ne s’applique 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. Vous ne pouvez pas rendre les paramètres facultatifs. Vous devez affecter une valeur par défaut 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 transmettre d’autres propriétés à des phases, étapes et travaux utilisés comme paramètres dans un modèle.

Quelle est la différence entre les paramètres et les variables ?

Le tableau suivant met en évidence les principales différences entre les paramètres et les variables dans Azure Pipelines.

Caractéristique Paramètres Variables
Temps d’évaluation Analyse de modèle (file d’attente) L’évaluation dépend de la syntaxe. Les variables définies avec la syntaxe de macro ($(var)) sont évaluées au moment de l’exécution avant l’exécution d’une tâche et utilisées dans les scripts et les tâches. Les variables définies avec des expressions d’exécution ($[variables.var]) sont évaluées avant l’exécution d’un travail ou d’une étape et sont utilisées dans des conditions ou une affectation de variable dynamique.
Mutabilité Immuable après la file d’attente Les variables définies par l’utilisateur, d’environnement et de sortie peuvent être mises à jour dynamiquement pendant l’exécution du pipeline
Exposition de l’interface utilisateur pendant l’exécution Illustré dans l’interface utilisateur du pipeline d’exécution et peut être défini avant une exécution Exposé pendant l'exécution si défini comme substituable dans l'interface utilisateur du Pipeline.
Valeurs secrètes Pas de support pour les valeurs secrètes Peut être défini en tant que secrets

Utiliser des paramètres dans les pipelines

Définissez les paramètres d’exécution 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 }}

Dans la page Exécutions du pipeline, sélectionnez Exécuter le pipeline pour exécuter le pipeline. Vous voyez l’option permettant de sélectionner l’image du pool. Si vous n’effectuez pas de sélection, l’option ubuntu-latest par défaut est utilisée. Vous ne pouvez pas sélectionner une image de pool si vous exécutez votre pipeline à partir de l’éditeur YAML.

Paramètres de runtime

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, testqui contrôle s’il faut exécuter des tests 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 est runPerfTests false. Par conséquent, seules trois des quatre étapes s’exécutent, sauf si vous mettez à jour la valeur.

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

Rechercher un objet de paramètre vide

Utilisez 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 Remarques
string ficelle
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 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, deployment, deploymentList, stage, stringList et stageList utilisent tous le format de schéma YAML standard. Cet exemple inclut string, , numberboolean, object, stepet stepList.

Notes

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}}

Meilleures pratiques en matière de sécurité des paramètres

Lorsque vous utilisez des paramètres d’exécution dans Azure Pipelines, ne transmettez pas de secrets ni de valeurs sensibles en tant qu’entrées de paramètre. Les valeurs de paramètre sont étendues au moment du parsing du modèle et peuvent être exposées dans les journaux de pipeline ou les sorties.

Validez et limitez toujours les valeurs de paramètres autorisées pour empêcher l’injection d’entrées inattendues ou non sécurisées. Suivez le principe du privilège minimum lors de l’octroi de l’accès aux ressources de pipeline.

Pour les informations d’identification, les jetons ou d’autres données confidentielles, utilisez des variables de pipeline marquées comme secrets et stockées dans Azure Key Vault, l’interface utilisateur du pipeline ou les groupes de variables. Pour plus d’informations, consultez Protéger les secrets dans Azure Pipelines.