Wyrażenia szablonu
Użyj wyrażeń szablonu, aby określić sposób dynamicznego rozpoznawania wartości podczas inicjowania potoku.
Zawijaj wyrażenie szablonu wewnątrz tej składni: ${{ }}
.
Wyrażenia szablonu mogą rozszerzać parametry szablonu, a także zmienne.
Możesz użyć parametrów, aby wpłynąć na sposób rozszerzenia szablonu.
Obiekt parameters
działa jak variables
obiekt w wyrażeniu. W wyrażeniach szablonu można używać tylko wstępnie zdefiniowanych zmiennych.
Uwaga
Wyrażenia są rozszerzane tylko dla stages
, , steps
jobs
i containers
(wewnątrz resources
).
Nie można na przykład użyć wyrażenia wewnątrz trigger
lub zasobu, takiego jak repositories
.
Ponadto w usłudze Azure DevOps 2020 RTW nie można używać wyrażeń szablonów wewnątrz containers
elementu .
Można na przykład zdefiniować szablon:
# File: steps/msbuild.yml
parameters:
- name: 'solution'
default: '**/*.sln'
type: string
steps:
- task: msbuild@1
inputs:
solution: ${{ parameters['solution'] }} # index syntax
- task: vstest@2
inputs:
solution: ${{ parameters.solution }} # property dereference syntax
Następnie odwołujesz się do szablonu i przekazujesz go opcjonalny solution
parametr:
# File: azure-pipelines.yml
steps:
- template: steps/msbuild.yml
parameters:
solution: my.sln
Kontekst
W wyrażeniu szablonu masz dostęp do parameters
kontekstu zawierającego wartości parametrów przekazanych.
Ponadto masz dostęp do kontekstu zawierającego variables
wszystkie zmienne określone w pliku YAML oraz wiele wstępnie zdefiniowanych zmiennych (zanotowanych na każdej zmiennej w tym artykule).
Co ważne, nie ma zmiennych środowiska uruchomieniowego, takich jak te przechowywane w potoku lub podane podczas uruchamiania przebiegu.
Rozszerzenie szablonu odbywa się na wczesnym etapie uruchamiania, więc te zmienne nie są dostępne.
Funkcje wyrażeń szablonu
Funkcje ogólne można używać w szablonach. Możesz również użyć kilku funkcji wyrażeń szablonu.
format
- Zamiana prostego tokenu ciągu
- Minimalne parametry: 2. Maksymalna liczba parametrów: N
- Przykład:
${{ format('{0} Build', parameters.os) }}
→'Windows Build'
Łączonej
- Oblicza pierwszy argument ciągu innego niż pusty, inny niż null
- Minimalne parametry: 2. Maksymalna liczba parametrów: N
- Przykład:
parameters:
- name: 'restoreProjects'
default: ''
type: string
- name: 'buildProjects'
default: ''
type: string
steps:
- script: echo ${{ coalesce(parameters.foo, parameters.bar, 'Nothing to see') }}
Wstawianie
Za pomocą wyrażeń szablonu można zmienić strukturę potoku YAML. Na przykład, aby wstawić do sekwencji:
# File: jobs/build.yml
parameters:
- name: 'preBuild'
type: stepList
default: []
- name: 'preTest'
type: stepList
default: []
- name: 'preSign'
type: stepList
default: []
jobs:
- job: Build
pool:
vmImage: 'windows-latest'
steps:
- script: cred-scan
- ${{ parameters.preBuild }}
- task: msbuild@1
- ${{ parameters.preTest }}
- task: vstest@2
- ${{ parameters.preSign }}
- script: sign
# File: .vsts.ci.yml
jobs:
- template: jobs/build.yml
parameters:
preBuild:
- script: echo hello from pre-build
preTest:
- script: echo hello from pre-test
Gdy tablica zostanie wstawiona do tablicy, zagnieżdżona tablica zostanie spłaszczone.
Aby wstawić element do mapowania, użyj właściwości ${{ insert }}
specjalnej .
# Default values
parameters:
- name: 'additionalVariables'
type: object
default: {}
jobs:
- job: build
variables:
configuration: debug
arch: x86
${{ insert }}: ${{ parameters.additionalVariables }}
steps:
- task: msbuild@1
- task: vstest@2
jobs:
- template: jobs/build.yml
parameters:
additionalVariables:
TEST_SUITE: L0,L1
Wstawianie warunkowe
Jeśli chcesz warunkowo wstawić do sekwencji lub mapowania w szablonie, użyj wstawiania i oceny wyrażeń. Można również używać if
instrukcji spoza szablonów , o ile używasz składni szablonu.
Aby na przykład wstawić do sekwencji w szablonie:
# File: steps/build.yml
parameters:
- name: 'toolset'
default: msbuild
type: string
values:
- msbuild
- dotnet
steps:
# msbuild
- ${{ if eq(parameters.toolset, 'msbuild') }}:
- task: msbuild@1
- task: vstest@2
# dotnet
- ${{ if eq(parameters.toolset, 'dotnet') }}:
- task: dotnet@1
inputs:
command: build
- task: dotnet@1
inputs:
command: test
# File: azure-pipelines.yml
steps:
- template: steps/build.yml
parameters:
toolset: dotnet
Aby na przykład wstawić do mapowania w szablonie:
# File: steps/build.yml
parameters:
- name: 'debug'
type: boolean
default: false
steps:
- script: tool
env:
${{ if eq(parameters.debug, true) }}:
TOOL_DEBUG: true
TOOL_DEBUG_DIR: _dbg
steps:
- template: steps/build.yml
parameters:
debug: true
Można również użyć wstawiania warunkowego dla zmiennych. W tym przykładzie zawsze drukuje i this is a test
drukuje tylko wtedy, start
gdy zmienna foo
jest test
równa .
variables:
- name: foo
value: test
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "start" # always runs
- ${{ if eq(variables.foo, 'test') }}:
- script: echo "this is a test" # runs when foo=test
Można również ustawić zmienne na podstawie wartości innych zmiennych. W poniższym potoku myVar
służy do ustawiania wartości conditionalVar
.
trigger:
- main
pool:
vmImage: 'ubuntu-latest'
variables:
- name: myVar
value: 'baz'
- name: conditionalVar
${{ if eq(variables['myVar'], 'foo') }}:
value: 'bar'
${{ elseif eq(variables['myVar'], 'baz') }}:
value: 'qux'
${{ else }}:
value: 'default'
steps:
- script: echo "start" # always runs
- ${{ if eq(variables.conditionalVar, 'bar') }}:
- script: echo "the value of myVar is set in the if condition" # runs when myVar=foo
- ${{ if eq(variables.conditionalVar, 'qux') }}:
- script: echo "the value of myVar is set in the elseif condition" # runs when myVar=baz
Wstawienie iteracyjne
Dyrektywa each
umożliwia iteracyjne wstawianie na podstawie sekwencji YAML (tablicy) lub mapowania (par klucz-wartość).
Można na przykład opakowować kroki poszczególnych zadań przy użyciu innych kroków wstępnych i po nich:
# job.yml
parameters:
- name: 'jobs'
type: jobList
default: []
jobs:
- ${{ each job in parameters.jobs }}: # Each job
- ${{ each pair in job }}: # Insert all properties other than "steps"
${{ if ne(pair.key, 'steps') }}:
${{ pair.key }}: ${{ pair.value }}
steps: # Wrap the steps
- task: SetupMyBuildTools@1 # Pre steps
- ${{ job.steps }} # Users steps
- task: PublishMyTelemetry@1 # Post steps
condition: always()
# azure-pipelines.yml
jobs:
- template: job.yml
parameters:
jobs:
- job: A
steps:
- script: echo This will get sandwiched between SetupMyBuildTools and PublishMyTelemetry.
- job: B
steps:
- script: echo So will this!
Możesz również manipulować właściwościami dowolnego iterowania. Aby na przykład dodać więcej zależności:
# job.yml
parameters:
- name: 'jobs'
type: jobList
default: []
jobs:
- job: SomeSpecialTool # Run your special tool in its own job first
steps:
- task: RunSpecialTool@1
- ${{ each job in parameters.jobs }}: # Then do each job
- ${{ each pair in job }}: # Insert all properties other than "dependsOn"
${{ if ne(pair.key, 'dependsOn') }}:
${{ pair.key }}: ${{ pair.value }}
dependsOn: # Inject dependency
- SomeSpecialTool
- ${{ if job.dependsOn }}:
- ${{ job.dependsOn }}
# azure-pipelines.yml
jobs:
- template: job.yml
parameters:
jobs:
- job: A
steps:
- script: echo This job depends on SomeSpecialTool, even though it's not explicitly shown here.
- job: B
dependsOn:
- A
steps:
- script: echo This job depends on both Job A and on SomeSpecialTool.
Ucieczka wartości
Jeśli musisz użyć wartości, która dosłownie zawiera ${{
wartość , zawijaj wartość w ciągu wyrażenia. Na przykład ${{ 'my${{value' }}
lub ${{ 'my${{value with a '' single quote too' }}