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.yml
systemie, 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 jobList
danych , deploymentList
lub 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 jobList
danych . testing-template.yml
Szablon tworzy nową zmienną testJob
przy użyciu każdego słowa kluczowego. Następnie szablon odwołuje się testJob.templateContext.expectedHTTPResponseCode
do 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
Parametry można przekazać do szablonów.
Sekcja parameters
definiuje, jakie parametry są dostępne w szablonie i ich wartości domyślne.
Szablony są rozszerzane tuż przed uruchomieniem potoku, aby wartości otoczone przez nie zostały zastąpione przez parametry odbierane ${{ }}
z otaczającego potoku. W związku z tym tylko wstępnie zdefiniowane zmienne mogą być używane w parametrach.
Aby użyć parametrów w wielu potokach, zobacz, jak utworzyć grupę zmiennych.
Szablony zadań, etapów i kroków z parametrami
# File: templates/npm-with-params.yml
parameters:
name: '' # defaults for any parameters that aren't specified
vmImage: ''
jobs:
- job: ${{ parameters.name }}
pool:
vmImage: ${{ parameters.vmImage }}
steps:
- script: npm install
- script: npm test
W przypadku korzystania z szablonu w potoku określ wartości parametrów szablonu.
# File: azure-pipelines.yml
jobs:
- template: templates/npm-with-params.yml # Template reference
parameters:
name: Linux
vmImage: 'ubuntu-latest'
- template: templates/npm-with-params.yml # Template reference
parameters:
name: macOS
vmImage: 'macOS-10.13'
- template: templates/npm-with-params.yml # Template reference
parameters:
name: Windows
vmImage: 'windows-latest'
Można również użyć parametrów z szablonami kroków lub etapów. Na przykład kroki z parametrami:
# File: templates/steps-with-params.yml
parameters:
runExtendedTests: 'false' # defaults for any parameters that aren't specified
steps:
- script: npm test
- ${{ if eq(parameters.runExtendedTests, 'true') }}:
- script: npm test --extended
W przypadku korzystania z szablonu w potoku określ wartości parametrów szablonu.
# File: azure-pipelines.yml
steps:
- script: npm install
- template: templates/steps-with-params.yml # Template reference
parameters:
runExtendedTests: 'true'
Uwaga
Parametry skalarne są zawsze traktowane jako ciągi.
Na przykład eq(parameters['myparam'], true)
funkcja będzie prawie zawsze zwracać true
wartość , nawet jeśli myparam
parametr jest wyrazem false
.
Ciągi niepuste są rzutowane do true
elementu w kontekście logicznym.
To wyrażenie może zostać przepisane w celu jawnego porównania ciągów: eq(parameters['myparam'], 'true')
.
Parametry nie są ograniczone do ciągów skalarnych. Jeśli tylko miejsce, w którym parametr się rozwija, oczekuje mapowania, parametr może być mapowaniem. Podobnie sekwencje mogą być przekazywane, gdy sekwencje są oczekiwane. Na przykład:
# azure-pipelines.yml
jobs:
- template: process.yml
parameters:
pool: # this parameter is called `pool`
vmImage: ubuntu-latest # and it's a mapping rather than a string
# process.yml
parameters:
pool: {}
jobs:
- job: build
pool: ${{ parameters.pool }}
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla