Udostępnij za pośrednictwem

Parametry środowiska uruchomieniowego

  • Artykuł

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ść falsena , 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.

parametry środowiska uruchomieniowego

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, testczy 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

Dynamiczne dołączanie listy kroków za pomocą parametru stepList

W tym przykładzie typ parametru stepList jest używany do dynamicznego uwzględnienia listy kroków w procesie kompilacji.

  • Główny potok (azure-pipelines.yml) definiuje dwa zadania: kompilowanie i wdrażanie.
  • Zadanie kompilacji używa szablonu (build.yml) i przekazuje listę zadań kompilacji przy użyciu parametru stepList .
  • Szablon build.yml dynamicznie zawiera kroki zdefiniowane w parametrze build_tasks .
#azure-pipelines.yml

trigger:
- main

jobs:
  - job: build
    displayName: 'Build .NET Core Application'
    pool:
      vmImage: 'ubuntu-latest'

    steps:
      - checkout: self

      - template: build.yml
        parameters:
          build_tasks:
            - task: DotNetCoreCLI@2
              displayName: 'Restore'
              inputs:
                command: 'restore'
                projects: '**/*.csproj'  

            - task: DotNetCoreCLI@2
              displayName: 'Build'
              inputs:
                command: 'build'
                arguments: '--no-restore'
                projects: '**/*.csproj' 

  - job: deploy
    displayName: 'Pack for Azure App Service deployment'
    dependsOn: build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - download: current
        artifact: drop

Szablon build.yml :

  • Definiuje parametr build_tasks z typem stepList i domyślną pustą listą.
  • Ustawia zestaw .NET Core SDK na 6.x.
  • Iteruje każdy krok w parametrze build_tasks .
  • Wykonuje każdy krok zdefiniowany na build_tasks liście.
#build.yml

parameters:
  - name: build_tasks
    type: stepList
    default: []

steps:
  - task: UseDotNet@2
    displayName: 'Use .NET Core SDK'
    inputs:
      packageType: 'sdk'
      version: '6.x'

  - ${{ each step in parameters.build_tasks }}:
      - ${{ step }}

  - task: DotNetCoreCLI@2
    displayName: 'Publish'
    inputs:
      command: 'publish'
      arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
      projects: '**/*.csproj'

  - task: PublishBuildArtifacts@1
    displayName: 'Publish Artifact'
    inputs:
      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
      ArtifactName: 'drop'

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  # 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'
  values:  # Allowed values for 'myMultiString'
  - default  
  - ubuntu  

- 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