Vorlagenparameter

Sie können Parameter und deren Datentypen in einer Vorlage angeben und in einer Pipeline auf diese Parameter verweisen. Verwenden Sie templateContext, um zusätzliche Eigenschaften an Stages, Schritte und Aufträge zu übergeben, die als Parameter in einer Vorlage verwendet werden.

Sie können Parameter auch außerhalb von Vorlagen verwenden. Für Parameterstandardwerte können Sie nur Literale verwenden. Weitere Informationen zu Parametern im YAML-Schema.

Übergeben von Parametern

Parameter müssen einen Namen und datentyp enthalten. Wenn azure-pipelines.ymlder Parameter yesNo auf einen booleschen Wert festgelegt ist, wird der Build erfolgreich ausgeführt. Wenn yesNo dieser Wert auf eine Zeichenfolge wie apples"Zeichenfolge" festgelegt ist, schlägt der Build fehl.

# 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

Verwenden von templateContext zum Übergeben von Eigenschaften an Vorlagen

Sie können mit templateContext weitere Eigenschaften an Stages, Schritte und Aufträge übergeben, die als Parameter in einer Vorlage verwendet werden. Insbesondere können Sie templateContext innerhalb der Parameterdatentypen jobList, deploymentList oder stageList angeben.

templateContext erleichtert das Einrichten von Umgebungen bei der Verarbeitung jedes Auftrags. Durch die Bündelung eines Auftrags und dessen Umgebungseigenschaftenobjekts templateContext kann yaML besser verwaltet und leichter verständlich werden.

In diesem Beispiel weist der Parameter testSet in testing-template.yml den Datentyp jobList auf. Die Vorlage testing-template.yml erstellt eine neue Variable testJob mit dem Schlüsselwort each. Die Vorlage verweist dann auf testJob.templateContext.expectedHTTPResponseCode, das in azure-pipeline.yml festgelegt und an die Vorlage übergeben wird.

Wenn der Antwortcode 200 ist, erstellt die Vorlage eine REST-Anforderung. Wenn der Antwortcode 500 ist, gibt die Vorlage alle Umgebungsvariablen für das Debuggen aus.

templateContext kann Eigenschaften enthalten.

#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"

Parameter zum Auswählen einer Vorlage zur Laufzeit

Je nach Bedingung können Sie verschiedene Vorlagen aus dem YAML-Code einer Pipeline aufrufen. In diesem Beispiel wird die YAML-Datei experimental.yml ausgeführt, wenn der Parameter experimentalTemplate TRUE ist.

#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

Parameterdatentypen

Datentyp	Notizen
`string`	Zeichenfolge
`stringList`	eine Liste von Elementen, mehrere können ausgewählt werden. In Vorlagen nicht verfügbar
`number`	kann auf `values:` beschränkt sein, andernfalls wird eine beliebige zahlenähnliche Zeichenfolge akzeptiert
`boolean`	`true` oder `false`
`object`	beliebige YAML-Struktur
`step`	ein einzelner Schritt
`stepList`	Sequenz von Schritten
`job`	ein einzelner Job
`jobList`	Sequenz von Aufträgen
`deployment`	ein einzelner Bereitstellungsauftrag
`deploymentList`	Sequenz von Bereitstellungsaufträgen
`stage`	eine einzelne Stufe
`stageList`	Abfolge von Phasen

Alle step, stepList, job, jobList, deployment, deploymentList, stage, stringList und stageList Datentypen verwenden das standardmäßige YAML-Schemaformat. Dieses Beispiel enthält string, , number, boolean, object, stepund stepList.

Hinweis

Der stringList Datentyp ist in Vorlagen nicht verfügbar. Verwenden Sie stattdessen den object Datentyp in Vorlagen.

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

Durchlaufen von Parametern und deren Datentypen

Mit Azure Pipelines können Sie Parameter verschiedener Datentypen durchlaufen, z. B. Zeichenfolgen, Objekte, Zahlen und Booleane. Diese Flexibilität ermöglicht das dynamische Pipelineverhalten basierend auf Parameterwerten. Im Folgenden finden Sie Beispiele, die zeigen, wie Sie Parameter durchlaufen und verschiedene Datentypen behandeln.

Durchlaufen einfacher Parameter

Sie können einfache Parameter wie Zeichenfolgen, Zahlen und Boolesche durchlaufen. In diesem Beispiel durchläuft die Pipeline eine Liste von Parametern und druckt deren Namen und Werte.

# 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

Durchlaufen von Objekten

Mit Objekten können Sie komplexe Parameterstrukturen definieren, z. B. geschachtelte Elemente. Sie können Objekte durchlaufen, um auf ihre Schlüssel und Werte oder geschachtelten Eigenschaften zuzugreifen.

Beispiel: Durchlaufen von Objektschlüsseln und -werten

Die folgende Vorlagendatei definiert den myObject Parameter als Objekt mit Standardschlüssel-Wert-Paaren. Der Auftrag durchläuft die Tasten und druckt ihre Werte.

# 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'

Die Pipeline setzt die Standardwerte mit myObject benutzerdefinierten Werten außer Kraft.

# azure-pipelines.yml

trigger:
- main

extends:
  template: object-keys-template.yml
  parameters:
    myObject:
      key1: 'customValue1'
      key2: 'customValue2'
      key3: 'customValue3'

Beispiel: Durchlaufen geschachtelter Objekte

Die Vorlage definiert einen listOfFruits Parameter, der Objekte mit geschachtelten Arrays enthält, und verwendet dann geschachtelte Schleifen, um jede Frucht und die zugehörigen Farben zu verarbeiten.

# 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

In der Pipelinedatei wird gezeigt, wie sie die Standardwerte mit benutzerdefinierten Fruchtdaten überschreiben.

# File: azure-pipelines.yml

trigger:
- main

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

Eine Liste von Schritten mit dem stepList-Parameter dynamisch einschließen

In diesem Beispiel wird der Parametertyp stepList verwendet, um dynamisch eine Liste der Schritte in den Buildprozess einzuschließen.

Die Hauptpipeline (azure-pipelines.yml) definiert zwei Aufträge: Erstellen und Bereitstellen.
Der Buildauftrag verwendet eine Vorlage (build.yml) und übergibt eine Liste von Buildaufgaben mithilfe des Parameters stepList.
Die Vorlage build.yml schließt die im Parameter build_tasks definierten Schritte dynamisch ein.

#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

Die build.yml-Vorlage:

Definiert den Parameter build_tasks mit dem stepList-Typ und einer standardmäßigen leeren Liste.
Legt das .NET Core SDK auf 8.x fest.
Durchläuft die einzelnen Schritte im Parameter build_tasks.
Führt jeden in der build_tasks-Liste definierten Schritt aus.

#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'

Feedback

War diese Seite hilfreich?

Last updated on 2025-12-17