Parametry szablonu

Parametry i ich typy danych można określić w szablonie i odwoływać się do tych parametrów w potoku. Za pomocą szablonuContext można również przekazywać właściwości do etapów, kroków i zadań, które są używane jako parametry w szablonie.

Można również użyć parametrów spoza szablonów. Literały można używać tylko dla wartości domyślnych parametrów. Dowiedz się więcej o parametrach w schemacie YAML.

Przekazywanie parametrów

Parametry muszą zawierać nazwę i typ danych. W azure-pipelines.ymlsystemie, gdy parametr yesNo jest ustawiony na wartość logiczną, kompilacja zakończy się powodzeniem. Gdy yesNo parametr jest ustawiony na ciąg, taki jak apples, kompilacja kończy się niepowodzeniem.

# 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

Przekazywanie właściwości do szablonów przy użyciu szablonu TemplateContext

Możesz użyć templateContext polecenia , aby przekazać więcej właściwości do etapów, kroków i zadań, które są używane jako parametry w szablonie. W szczególności można określić templateContext typ jobListdanych , deploymentListlub stageList parametru.

Możesz użyć templateContext polecenia , aby ułatwić konfigurowanie środowisk podczas przetwarzania każdego zadania. Dzięki połączeniu zadania i jego właściwości środowiska można łatwiej templateContext zrozumieć kod YAML.

W tym przykładzie parametr testSet w testing-template.yml pliku ma typ jobListdanych . testing-template.yml Szablon tworzy nową zmienną testJob przy użyciu każdego słowa kluczowego. Następnie szablon odwołuje się testJob.templateContext.expectedHTTPResponseCodedo elementu , który zostanie ustawiony azure-pipeline.yml i przekazany do szablonu.

Gdy kod odpowiedzi to 200, szablon wysyła żądanie REST. Gdy kod odpowiedzi to 500, szablon zwraca wszystkie zmienne środowiskowe na potrzeby debugowania.

templateContext może zawierać właściwości.

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

Parametry wybierania szablonu w czasie wykonywania

W zależności od warunku można wywoływać różne szablony z potoku YAML. W tym przykładzie experimental.yml kod YAML jest uruchamiany, gdy parametr experimentalTemplate ma wartość 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

Typy danych parametrów

Typ danych	Uwagi
string	string
number	może być ograniczony do values:, w przeciwnym razie akceptowany jest dowolny ciąg przypominający liczbę
boolean	true lub false
object	dowolna struktura YAML
step	pojedynczy krok
stepList	sekwencja kroków
job	pojedyncze zadanie
jobList	sekwencja zadań
deployment	pojedyncze zadanie wdrożenia
deploymentList	sekwencja zadań wdrażania
stage	pojedynczy etap
stageList	sekwencja etapów

Wszystkie typy danych stepList, jobList, jobList, deployment, deploymentList, stage i stageList używają standardowego formatu schematu YAML. Ten przykład obejmuje ciąg, liczbę, wartość logiczną, obiekt, krok i listę kroków.

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

Można iterować przez obiekt i drukować każdy ciąg w obiekcie.

parameters:
- name: listOfStrings
  type: object
  default:
  - one
  - two

steps:
- ${{ each value in parameters.listOfStrings }}:
  - script: echo ${{ value }}

Ponadto można iterować przez zagnieżdżone elementy w obiekcie.

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

Parametry wymagane

Możesz dodać krok weryfikacji na początku szablonu, aby sprawdzić wymagane parametry.

Oto przykład, który sprawdza parametr przy użyciu powłoki solution Bash (co umożliwia działanie na dowolnej platformie):

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

Aby pokazać, że szablon nie powiedzie się, jeśli brakuje wymaganego parametru:

# 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