Udostępnij przez


Parametry środowiska uruchomieniowego

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Parametry środowiska uruchomieniowego zapewniają większą kontrolę nad wartościami przekazywanymi 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 pipeline. 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 podczas analizowania szablonów. Rozwijają się przed uruchomieniem potoku, zastępując wartości otoczone znacznikami ${{ }} wartościami parametrów. Użyj zmiennych , jeśli wartości muszą być dostępne w całym przebiegu 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. Nie można ustawić parametrów opcjonalnych. Musisz przypisać wartość domyślną w pliku YAML lub przy uruchamianiu potoku. Jeśli nie przypiszesz wartości domyślnej lub ustawisz default wartość falsena , zostanie użyta pierwsza dostępna wartość.

Użyj templateContext, aby przekazać więcej właściwości do etapów, kroków i zadań używanych jako parametry w szablonie.

Jaka jest różnica między parametrami i zmiennymi?

W poniższej tabeli przedstawiono kluczowe różnice między parametrami i zmiennymi w usłudze Azure Pipelines.

Funkcja Parametry Zmiennych
Czas oceny Analizowanie szablonów (kolejka) Ocena jest zależna od składni. Zmienne zdefiniowane za pomocą składni makr ($(var)) są obliczane w czasie wykonywania, zanim zadanie zostanie uruchomione, a następnie używane w skryptach i zadaniach. Zmienne zdefiniowane za pomocą wyrażeń środowiska uruchomieniowego ($[variables.var]) są obliczane przed uruchomieniem zadania lub etapu i są używane w warunkach lub przypisania zmiennej dynamicznej.
Możliwość mutowania Niezmienne po kolejce Zmienne zdefiniowane przez użytkownika, zmienne środowiskowe i zmienne wyjściowe można aktualizować dynamicznie podczas wykonywania potoku
Narażenie interfejsu użytkownika podczas uruchamiania Wyświetlane w interfejsie użytkownika Run Pipeline i można ustawić przed uruchomieniem Uwidocznione podczas uruchamiania, jeśli ustawiono w Pipeline UI jako dające się zastąpić.
Tajne wartości Brak obsługi wartości wpisów tajnych Można ustawić jako wpisy tajne

Używanie parametrów w potokach

Ustaw parametry środowiska uruchomieniowego na początku pliku YAML.

Ten przykładowy image pipeline zawiera parametr z trzema hostowanymi agentami jako opcje string. W sekcji pool zadań wartość określa agenta z parametru używanego do uruchamiania zadania. Parametr trigger jest ustawiony na brak, aby móc wybrać wartość image podczas ręcznego wyzwalania uruchomienia potoku.

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

Na stronie Przebiegi potoku wybierz pozycję Uruchom potok , aby uruchomić potok. Zostanie wyświetlona opcja wybrania obrazu puli. Jeśli nie wybierzesz opcji, zostanie użyta opcja ubuntu-latest domyślna. Nie można wybrać obrazu puli, jeśli uruchomisz potok w edytorze YAML.

parametry środowiska uruchomieniowego

Używanie warunkowych z parametrami

Można również użyć parametrów w ramach logiki warunkowej. Przy użyciu warunków, część pliku YAML jest uruchamiana, jeśli spełnia if kryteria.

Użyj parametrów, aby określić, jakie kroki są uruchamiane

Ten pipeline dodaje drugi parametr logiczny test, który kontroluje, czy uruchamiać testy w tym pipeline. Gdy test jest równe true, wykonywany jest krok, który obejmuje 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ą kompilowane w zależności od wartości parametru config, który jest typem string. Domyślnie zarówno x86, jak i x64 są budowane.

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 ciąg technologiczny 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 tylko trzy z czterech etapów są uruchamiane, chyba że wartość zostanie zaktualizowana.

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

Sprawdzanie pustego obiektu parametru

length() Użyj 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 ciąg
stringList Lista elementów, z których można wybrać wiele. Niedostępne w szablonach
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

Typy danych step, stepList, job, jobList, deployment, deploymentList, stage, stringList i stageList wszystkie używają standardowego formatu schematu YAML. Ten przykład obejmuje string, number, boolean, object, step i stepList.

Uwaga

Typ stringList danych nie jest dostępny w szablonach. Użyj typu danych object w szablonach zamiast tego.

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

Najlepsze rozwiązania dotyczące zabezpieczeń parametrów

Jeśli używasz parametrów środowiska uruchomieniowego w usłudze Azure Pipelines, nie przekazuj tajnych danych ani wartości poufnych jako danych wejściowych parametrów. Wartości parametrów są rozszerzane w czasie analizowania szablonów i mogą być uwidocznione w dziennikach potoku lub danych wyjściowych.

Zawsze weryfikuj i ograniczaj dozwolone wartości parametrów, aby zapobiec wstrzyknięciu nieoczekiwanych lub niebezpiecznych danych wejściowych. Przestrzegaj zasady najniższych uprawnień podczas udzielania dostępu do zasobów potoku.

W przypadku poświadczeń, tokenów lub innych poufnych danych użyj zmiennych potoku przechowywanych w usłudze Azure Key Vault, w interfejsie użytkownika potoku lub w grupach zmiennych, oznaczonych jako tajne. Aby uzyskać więcej informacji, zobacz Chronienie tajemnic w Azure Pipelines.