Parametry środowiska uruchomieniowego
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
Parametry środowiska uruchomieniowego umożliwiają większą kontrolę nad wartościami, które można przekazać do potoku. Za pomocą parametrów środowiska uruchomieniowego można wykonywać następujące czynności:
- Podaj różne wartości skryptów i zadań w czasie wykonywania
- Kontrolowanie typów parametrów, dozwolonych zakresów i wartości domyślnych
- Dynamiczne wybieranie zadań i etapów za pomocą wyrażeń szablonu
Parametry można określić w szablonach i w potoku. Parametry mają typy danych, takie jak liczba i ciąg, i mogą być ograniczone do podzestawu wartości. Sekcja parameters
w języku YAML definiuje, jakie parametry są dostępne.
Parametry są dostępne tylko w czasie analizowania szablonów. Parametry są rozszerzane tuż przed uruchomieniem potoku, aby wartości otoczone ${{ }}
wartościami parametrów zostały zastąpione wartościami parametrów. Użyj zmiennych, jeśli wartości będą bardziej powszechnie dostępne podczas uruchamiania potoku.
Uwaga
Te wskazówki nie dotyczą potoków klasycznych. Aby uzyskać informacje o parametrach w potokach klasycznych, zobacz Parametry procesu (wersja klasyczna).
Parametry muszą zawierać nazwę i typ danych. Parametry nie mogą być opcjonalne. Wartość domyślna musi być przypisana w pliku YAML lub podczas uruchamiania potoku. Jeśli nie przypiszesz wartości domyślnej lub ustawisz default
wartość false
na , zostanie użyta pierwsza dostępna wartość.
Użyj szablonuContext , aby przekazać dodatkowe właściwości do etapów, kroków i zadań, które są używane jako parametry w szablonie.
Używanie parametrów w potokach
Ustaw parametry środowiska uruchomieniowego na początku kodu YAML.
Ten przykładowy image
potok zawiera parametr z trzema hostowanymi agentami jako string
opcjami. W sekcji pool
zadań wartość określa agenta z parametru używanego do uruchamiania zadania. Parametr trigger
jest ustawiony na wartość brak, aby można było wybrać wartość image
po ręcznym wyzwoleniu potoku do uruchomienia.
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 }}
Po uruchomieniu potoku wybierz obraz puli. Jeśli nie wybierzesz opcji , zostanie użyta opcja ubuntu-latest
domyślna.
Używanie warunkowych z parametrami
Można również użyć parametrów w ramach logiki warunkowej. W przypadku warunkowych część kodu YAML jest uruchamiana, jeśli spełnia if
kryteria.
Użyj parametrów, aby określić, jakie kroki są uruchamiane
Ten potok dodaje drugi parametr logiczny , który może służyć do kontrolowania, test
czy uruchamiać testy w potoku. Gdy wartość test
ma wartość true, krok, który zwraca wartość Running all the tests run (Uruchamianie wszystkich testów ).
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"
Ustawianie używanej konfiguracji przy użyciu parametrów
Możesz również użyć parametrów, aby ustawić, które zadanie jest uruchamiane. W tym przykładzie różne architektury są kompilować w zależności od wartości parametru config
, który jest typem string
. Domyślnie zarówno kompilacja architektury, jak x86
i x64
.
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...
Selektywne wykluczanie etapu
Możesz również użyć parametrów, aby ustawić, czy etap jest uruchamiany. W tym przykładzie istnieje potok z czterema etapami i różnymi zadaniami dla każdego etapu. Etap testu wydajnościowego jest uruchamiany, jeśli parametr runPerfTests
ma wartość true. Wartość domyślna runPerfTests
to false, więc bez żadnych aktualizacji uruchamiane są tylko trzy z czterech etapów.
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
Pętla przez parametry
Możesz również przechodzić w pętli przez parametry ciągu, liczby i wartości logicznej.
W tym przykładzie przejmiesz pętlę przez parametry i wyświetlisz nazwę i wartość każdego parametru. Istnieją cztery różne parametry, a każdy reprezentuje inny typ. myStringName
jest ciągiem jednowierszowym. myMultiString
jest ciągiem wielowierszowym. myNumber
jest liczbą. myBoolean
jest wartością logiczną. W sekcji kroków zadania skryptu generują klucz i wartość każdego parametru.
# start.yaml
parameters:
- name: myStringName
type: string
default: a string value
- 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
steps:
- ${{ each parameter in parameters }}:
- script: echo ${{ parameter.Key }}
- script: echo ${{ parameter.Value }}
# azure-pipeline.yaml
trigger: none
extends:
template: start.yaml
Sprawdzanie pustego obiektu parametru
Możesz użyć length()
wyrażenia , aby sprawdzić, czy parametr obiektu nie ma wartości.
parameters:
- name: foo
type: object
default: []
steps:
- checkout: none
- ${{ if eq(length(parameters.foo), 0) }}:
- script: echo Foo is empty
displayName: Foo is empty
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 }}
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