Definiowanie zmiennych

  • Artykuł
  • Czas czytania: 37 min

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

Uwaga

W Microsoft Team Foundation Server (TFS) 2018 i poprzednich wersjach potoki kompilacji i wydania są nazywane definicjami, przebiegi są nazywane kompilacjami, połączenia usług są nazywane punktami końcowymi usługi, etapami są nazywane środowiskami, a zadania są nazywane fazami.

Zmienne zapewniają wygodny sposób pobierania kluczowych bitów danych do różnych części potoku. Najczęstszym zastosowaniem zmiennych jest zdefiniowanie wartości, której można następnie użyć w potoku. Wszystkie zmienne są przechowywane jako ciągi i są modyfikowalne. Wartość zmiennej może ulec zmianie z uruchomienia na uruchomienie lub zadanie do zadania potoku.

Podczas definiowania tej samej zmiennej w wielu miejscach o tej samej nazwie najbardziej lokalnie ograniczona zmienna wygrywa. W związku z tym zmienna zdefiniowana na poziomie zadania może zastąpić zmienną ustawioną na poziomie etapu. Zmienna zdefiniowana na poziomie etapu zastąpi zmienną ustawioną na poziomie głównym potoku. Zmienna ustawiona na poziomie głównym potoku zastąpi zmienną ustawioną w interfejsie użytkownika ustawień potoku.

Zmienne z wyrażeniami umożliwiają warunkowe przypisywanie wartości i dalsze dostosowywanie potoków.

Zmienne różnią się od parametrów środowiska uruchomieniowego, które są wpisywane i dostępne podczas analizowania szablonu.

Zmienne zdefiniowane przez użytkownika

Podczas definiowania zmiennej można użyć różnych składni (makro, wyrażenie szablonu lub środowisko uruchomieniowe) i składni, która będzie używana, określi, gdzie w potoku będzie renderowana zmienna.

W potokach YAML można ustawić zmienne na poziomie głównym, etapu i zadania. Możesz również określić zmienne poza potokiem YAML w interfejsie użytkownika. Po ustawieniu zmiennej w interfejsie użytkownika ta zmienna może być szyfrowana i ustawiana jako wpis tajny.

Zmienne zdefiniowane przez użytkownika można ustawić jako tylko do odczytu. Istnieją ograniczenia nazewnictwa zmiennych (na przykład: nie można użyć secret na początku nazwy zmiennej).

Możesz użyć grupy zmiennych , aby udostępnić zmienne w wielu potokach.

Szablony umożliwiają definiowanie zmiennych używanych w wielu potokach w jednym pliku.

Zmienne systemu

Oprócz zmiennych zdefiniowanych przez użytkownika Azure Pipelines ma zmienne systemowe ze wstępnie zdefiniowanymi wartościami. Jeśli używasz potoków YAML lub klasycznych potoków kompilacji, zobacz wstępnie zdefiniowane zmienne , aby uzyskać kompleksową listę zmiennych systemowych. Jeśli używasz klasycznych potoków wydania, zobacz Zmienne wydania.

Zmienne systemowe są ustawiane przy użyciu ich bieżącej wartości podczas uruchamiania potoku. Niektóre zmienne są ustawiane automatycznie. Jako autor potoku lub użytkownik końcowy zmienia wartość zmiennej systemowej przed uruchomieniem potoku.

Zmienne systemowe są tylko do odczytu.

Zmienne środowiskowe

Zmienne środowiskowe są specyficzne dla używanego systemu operacyjnego. Są one wstrzykiwane do potoku na sposoby specyficzne dla platformy. Format odpowiada sposobowi formatowania zmiennych środowiskowych dla określonej platformy skryptów.

W systemach system UNIX (macOS i Linux) zmienne środowiskowe mają format $NAME. W Windows format jest %NAME% przeznaczony dla partii i $env:NAME w programie PowerShell.

Zmienne systemowe i zdefiniowane przez użytkownika również są wstrzykiwane jako zmienne środowiskowe dla platformy. Gdy zmienne są przekształcane w zmienne środowiskowe, nazwy zmiennych stają się wielkie litery, a kropki zamieniają się w podkreślenia. Na przykład nazwa any.variable zmiennej staje się nazwą $ANY_VARIABLEzmiennej .

Istnieją ograniczenia nazewnictwa zmiennych zmiennych środowiskowych (na przykład: nie można użyć secret na początku nazwy zmiennej).

Ograniczenia nazewnictwa zmiennych

Zmienne środowiskowe zdefiniowane przez użytkownika mogą składać się z liter, cyfr, .znaków i _ znaków. Nie używaj prefiksów zmiennych zarezerwowanych przez system. Oto: endpoint, , input, secret, pathi securefile. Każda zmienna rozpoczynająca się od jednego z tych ciągów (niezależnie od wielkich liter) nie będzie dostępna dla zadań i skryptów.

Omówienie składni zmiennych

Azure Pipelines obsługuje trzy różne sposoby odwoływania się do zmiennych: makro, wyrażenie szablonu i wyrażenie środowiska uruchomieniowego. Każda składnia może być używana w innym celu i ma pewne ograniczenia.

W potoku zmienne wyrażeń szablonu (${{ variables.var }}) są przetwarzane w czasie kompilacji przed rozpoczęciem środowiska uruchomieniowego. Zmienne składni makra ($(var)) są przetwarzane podczas wykonywania przed uruchomieniem zadania. Wyrażenia środowiska uruchomieniowego ($[variables.var]) są również przetwarzane podczas wykonywania, ale zostały zaprojektowane do użytku z warunkami i wyrażeniami. Gdy używasz wyrażenia środowiska uruchomieniowego, musi on podjąć całą prawą stronę definicji.

W tym przykładzie widać, że wyrażenie szablonu nadal ma początkową wartość zmiennej po zaktualizowaniu zmiennej. Wartość aktualizacji zmiennej składni makra. Wartość wyrażenia szablonu nie zmienia się, ponieważ wszystkie zmienne wyrażeń szablonu są przetwarzane w czasie kompilacji przed uruchomieniem zadań. Natomiast zmienne składni makr są oceniane przed każdym uruchomieniem zadania.

variables:
- name: one
  value: initialValue 

steps:
  - script: |
      echo ${{ variables.one }} # outputs initialValue
      echo $(one)
    displayName: First variable pass
  - bash: echo "##vso[task.setvariable variable=one]secondValue"
    displayName: Set new variable value
  - script: |
      echo ${{ variables.one }} # outputs initialValue
      echo $(one) # outputs secondValue
    displayName: Second variable pass

Zmienne składni makr

Większość przykładów dokumentacji używa składni makr ($(var)). Składnia makr została zaprojektowana tak, aby interpolować wartości zmiennych do danych wejściowych zadań i innych zmiennych.

Zmienne ze składnią makr są przetwarzane przed wykonaniem zadania w czasie wykonywania. Środowisko uruchomieniowe odbywa się po rozszerzeniu szablonu. Gdy system napotka wyrażenie makra, zastępuje wyrażenie zawartością zmiennej. Jeśli nie ma zmiennej o tej nazwie, wyrażenie makra pozostanie niezmienione. Jeśli na przykład $(var) nie można zastąpić, $(var) nie zostanie zastąpiony przez nic.

Zmienne składni makr pozostają niezmienione bez wartości, ponieważ pusta wartość $() może oznaczać coś dla uruchomionego zadania, a agent nie powinien zakładać, że ta wartość została zamieniona. Jeśli na przykład używasz $(foo) metody do odwoływania się do zmiennej foo w zadaniu powłoki Bash, zastąpienie wszystkich $() wyrażeń w danych wejściowych do zadania może spowodować przerwanie skryptów powłoki Bash.

Zmienne makr są rozszerzane tylko wtedy, gdy są używane dla wartości, a nie jako słowa kluczowego. Wartości są wyświetlane po prawej stronie definicji potoku. Następujące elementy są prawidłowe: key: $(value). Następujące elementy nie są prawidłowe: $(key): value. Zmienne makr nie są rozszerzane, gdy są używane do wyświetlania wbudowanej nazwy zadania. Zamiast tego należy użyć displayName właściwości .

Uwaga

Zmienne składni makr są rozszerzane tylko dla stages, jobsi steps. Nie można na przykład użyć składni makr wewnątrz elementu resource lub trigger.

W tym przykładzie składnia makr jest używana z powłoką Bash, programem PowerShell i zadaniem skryptu. Składnia wywoływania zmiennej ze składnią makr jest taka sama dla wszystkich trzech.

variables:
 - name: projectName
   value: contoso

steps: 
- bash: echo $(projectName)
- powershell: echo $(projectName)
- script: echo $(projectName)

Składnia wyrażeń szablonu

Składnia wyrażeń szablonu umożliwia rozwinięcie parametrów szablonu i zmiennych (${{ variables.var }}). Zmienne szablonu są przetwarzane w czasie kompilacji i są zastępowane przed rozpoczęciem środowiska uruchomieniowego. Wyrażenia szablonów są przeznaczone do ponownego użytku części YAML jako szablonów.

Zmienne szablonu dyskretnie łączą się z pustymi ciągami, gdy nie znaleziono wartości zastępczej. Wyrażenia szablonu, w przeciwieństwie do wyrażeń makr i środowiska uruchomieniowego, mogą być wyświetlane jako klucze (po lewej stronie) lub wartości (po prawej stronie). Następujące elementy są prawidłowe: ${{ variables.key }} : ${{ variables.value }}.

Składnia wyrażeń środowiska uruchomieniowego

Składnię wyrażeń środowiska uruchomieniowego można użyć dla zmiennych, które są rozwinięte w czasie wykonywania ($[variables.var]). Zmienne wyrażeń środowiska uruchomieniowego w trybie dyskretnym łączą się z pustymi ciągami, gdy nie znaleziono wartości zastępczej. Wyrażenia środowiska uruchomieniowego są przeznaczone do użycia w warunkach zadań, w celu obsługi warunkowego wykonywania zadań lub całych etapów.

Zmienne wyrażeń uruchomieniowych są rozszerzane tylko wtedy, gdy są używane dla wartości, a nie jako słowo kluczowe. Wartości są wyświetlane po prawej stronie definicji potoku. Następujące elementy są prawidłowe: key: $[variables.value]. Następujące elementy nie są prawidłowe: $[variables.key]: value. Wyrażenie środowiska uruchomieniowego musi przejąć całą prawą stronę pary klucz-wartość. Na przykład jest prawidłowy, key: $[variables.value] ale key: $[variables.value] foo nie.

Składnia Przykład Kiedy jest przetwarzany? Gdzie rozwija się w definicji potoku? Jak jest renderowany, gdy nie zostanie znaleziony?
Makro $(var) środowisko uruchomieniowe przed wykonaniem zadania wartość (po prawej stronie) Drukuje $(var)
wyrażenie szablonu ${{ variables.var }} czas kompilacji klucz lub wartość (po lewej lub prawej stronie) pusty ciąg
wyrażenie środowiska uruchomieniowego $[variables.var] środowisko uruchomieniowe wartość (po prawej stronie) pusty ciąg

Jakiej składni należy użyć?

Użyj składni makra, jeśli podajesz dane wejściowe dla zadania.

Wybierz wyrażenie środowiska uruchomieniowego, jeśli pracujesz z warunkami i wyrażeniami. Wyjątkiem od tego jest sytuacja, gdy masz potok, w którym wystąpi problem z pustą zmienną do wydrukowania. Jeśli na przykład masz logikę warunkową, która opiera się na zmiennej o określonej wartości lub bez wartości. W takim przypadku należy użyć wyrażenia środowiska uruchomieniowego.

Jeśli definiujesz zmienną w szablonie, użyj wyrażenia szablonu.

Ustawianie zmiennych w potoku

W najbardziej typowym przypadku należy ustawić zmienne i używać ich w pliku YAML. Dzięki temu można śledzić zmiany zmiennej w systemie kontroli wersji. Zmienne można również definiować w interfejsie użytkownika ustawień potoku (zobacz kartę Klasyczna) i odwoływać się do nich w języku YAML.

Oto przykład pokazujący, jak ustawić dwie zmienne i configurationplatform, i użyć ich w dalszej części kroków. Aby użyć zmiennej w instrukcji YAML, zawijaj ją w pliku $(). Zmiennych nie można użyć do zdefiniowania elementu repository w instrukcji YAML.

# Set variables once
variables:
  configuration: debug
  platform: x64

steps:

# Use them once
- task: MSBuild@1
  inputs:
    solution: solution1.sln
    configuration: $(configuration) # Use the variable
    platform: $(platform)

# Use them again
- task: MSBuild@1
  inputs:
    solution: solution2.sln
    configuration: $(configuration) # Use the variable
    platform: $(platform)

Zakresy zmiennych

W pliku YAML można ustawić zmienną w różnych zakresach:

  • Na poziomie głównym, aby udostępnić je wszystkim zadaniam w potoku.
  • Na poziomie etapu, aby udostępnić go tylko dla określonego etapu.
  • Na poziomie zadania, aby udostępnić je tylko dla określonego zadania.

Po zdefiniowaniu zmiennej w górnej części kodu YAML będzie ona dostępna dla wszystkich zadań i etapów w potoku i jest zmienną globalną. Zmienne globalne zdefiniowane w języku YAML nie są widoczne w interfejsie użytkownika ustawień potoku.

Zmienne na poziomie zadania zastępują zmienne na poziomie głównym i na poziomie etapu. Zmienne na poziomie etapu zastępują zmienne na poziomie głównym.

variables:
  global_variable: value    # this is available to all jobs

jobs:
- job: job1
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    job_variable1: value1    # this is only available in job1
  steps:
  - bash: echo $(global_variable)
  - bash: echo $(job_variable1)
  - bash: echo $JOB_VARIABLE1 # variables are available in the script environment too

- job: job2
  pool:
    vmImage: 'ubuntu-latest'
  variables:
    job_variable2: value2    # this is only available in job2
  steps:
  - bash: echo $(global_variable)
  - bash: echo $(job_variable2)
  - bash: echo $GLOBAL_VARIABLE

Dane wyjściowe obu zadań wyglądają następująco:

# job1
value 
value1
value1

# job2
value
value2
value

Określanie zmiennych

W poprzednich przykładach variables słowo kluczowe następuje lista par klucz-wartość. Klucze są nazwami zmiennych, a wartości są wartościami zmiennych.

Istnieje inna składnia, przydatna, gdy chcesz użyć szablonów zmiennych lub grup zmiennych. Ta składnia powinna być używana na poziomie głównym potoku.

W tej alternatywnej składni variables słowo kluczowe przyjmuje listę specyfikatorów zmiennych. Specyfikatory zmiennych są name dla zmiennej regularnej, group dla grupy zmiennych i template do uwzględnienia szablonu zmiennej. W poniższym przykładzie pokazano wszystkie trzy.

variables:
# a regular variable
- name: myvariable
  value: myvalue
# a variable group
- group: myvariablegroup
# a reference to a variable template
- template: myvariabletemplate.yml

Dowiedz się więcej o ponownym użyciu zmiennych za pomocą szablonów.

Uzyskiwanie dostępu do zmiennych za pośrednictwem środowiska

Zwróć uwagę, że zmienne są również udostępniane skryptom za pośrednictwem zmiennych środowiskowych. Składnia używania tych zmiennych środowiskowych zależy od języka skryptowego.

Nazwa jest wielkie litery, a . element jest zastępowany symbolem _. Jest to automatycznie wstawione do środowiska procesu. Oto kilka przykładów:

  • Skrypt usługi Batch: %VARIABLE_NAME%
  • Skrypt programu PowerShell: $env:VARIABLE_NAME
  • Skrypt powłoki Bash: $VARIABLE_NAME

Ważne

Wstępnie zdefiniowane zmienne zawierające ścieżki plików są tłumaczone na odpowiednie style (Windows stylu C:\foo\ a styl systemu Unix /foo/) na podstawie typu hosta agenta i typu powłoki. Jeśli uruchamiasz zadania skryptu powłoki bash na Windows, należy użyć metody zmiennej środowiskowej w celu uzyskania dostępu do tych zmiennych, a nie metody zmiennej potoku, aby upewnić się, że masz poprawny styl ścieżki pliku.

Kod YAML nie jest obsługiwany w programie TFS.

Ustawianie zmiennych tajnych

Nie ustawiaj zmiennych tajnych w pliku YAML. Systemy operacyjne często rejestrują polecenia dla uruchomionych procesów i nie chcesz, aby dziennik zawierał wpis tajny przekazany jako dane wejściowe. Użyj środowiska skryptu lub zamapuj variables zmienną w bloku, aby przekazać wpisy tajne do potoku.

Musisz ustawić zmienne tajne w interfejsie użytkownika ustawień potoku dla potoku. Te zmienne są ograniczone do potoku, w którym zostały ustawione. Zmienne tajne można również ustawić w grupach zmiennych.

Aby ustawić wpisy tajne w interfejsie internetowym, wykonaj następujące kroki:

  1. Przejdź do strony Pipelines, wybierz odpowiedni potok, a następnie wybierz pozycję Edytuj.
  2. Znajdź zmienne dla tego potoku.
  3. Dodaj lub zaktualizuj zmienną.
  4. Wybierz ikonę blokady, Secret aby przechowywać zmienną w zaszyfrowany sposób.
  5. Zapisz potok.

Zmienne tajne są szyfrowane w spoczynku przy użyciu klucza RSA 2048-bitowego. Wpisy tajne są dostępne w agencie pod kątem zadań i skryptów do użycia. Uważaj, kto ma dostęp do zmiany potoku.

Ważne

Staramy się maskować wpisy tajne przed pojawieniem się w Azure Pipelines danych wyjściowych, ale nadal trzeba podjąć środki ostrożności. Nigdy nie echo wpisów tajnych jako danych wyjściowych. Niektóre argumenty wiersza polecenia dziennika systemów operacyjnych. Nigdy nie przekazuj wpisów tajnych w wierszu polecenia. Zamiast tego zalecamy mapowania wpisów tajnych na zmienne środowiskowe.

Nigdy nie maskujemy podciągów wpisów tajnych. Jeśli na przykład ciąg "abc123" jest ustawiony jako wpis tajny, "abc" nie jest maskowany z dzienników. Ma to na celu uniknięcie maskowania wpisów tajnych na zbyt szczegółowym poziomie, dzięki czemu dzienniki są nieczytelne. Z tego powodu wpisy tajne nie powinny zawierać danych strukturalnych. Jeśli na przykład "{ "foo": "bar" }" jest ustawiony jako wpis tajny, "pasek" nie jest maskowany z dzienników.

W przeciwieństwie do zmiennej normalnej, nie są one automatycznie odszyfrowywane do zmiennych środowiskowych dla skryptów. Należy jawnie mapować zmienne tajne.

W poniższym przykładzie pokazano, jak używać zmiennej tajnej o nazwie mySecret w programie PowerShell i skryptach powłoki Bash. W przeciwieństwie do normalnej zmiennej potoku nie ma zmiennej środowiskowej o nazwie MYSECRET.

variables:
 GLOBAL_MYSECRET: $(mySecret) # this will not work because the secret variable needs to be mapped as env
 GLOBAL_MY_MAPPED_ENV_VAR: $(nonSecretVariable) # this works because it's not a secret.

steps:

- powershell: |
    Write-Host "Using an input-macro works: $(mySecret)"
    Write-Host "Using the env var directly does not work: $env:MYSECRET"
    Write-Host "Using a global secret var mapped in the pipeline does not work either: $env:GLOBAL_MYSECRET"
    Write-Host "Using a global non-secret var mapped in the pipeline works: $env:GLOBAL_MY_MAPPED_ENV_VAR" 
    Write-Host "Using the mapped env var for this task works and is recommended: $env:MY_MAPPED_ENV_VAR"
  env:
    MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable

- bash: |
    echo "Using an input-macro works: $(mySecret)"
    echo "Using the env var directly does not work: $MYSECRET"
    echo "Using a global secret var mapped in the pipeline does not work either: $GLOBAL_MYSECRET"
    echo "Using a global non-secret var mapped in the pipeline works: $GLOBAL_MY_MAPPED_ENV_VAR" 
    echo "Using the mapped env var for this task works and is recommended: $MY_MAPPED_ENV_VAR"
  env:
    MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable

Dane wyjściowe z obu zadań w poprzednim skry skrycie będą wyglądać następująco:

Using an input-macro works: ***
Using the env var directly does not work:
Using a global secret var mapped in the pipeline does not work either:
Using a global non-secret var mapped in the pipeline works: foo
Using the mapped env var for this task works and is recommended: ***

Można również używać zmiennych tajnych poza skryptami. Na przykład można mapować zmienne tajne na zadania przy użyciu variables definicji. W tym przykładzie pokazano, jak używać zmiennych tajnych $(vmsUser) i $(vmsAdminPass) w zadaniu kopiowania plików platformy Azure.

variables:
  VMS_USER: $(vmsUser)
  VMS_PASS: $(vmsAdminPass)

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: AzureFileCopy@4
  inputs:
    SourcePath: 'my/path'
    azureSubscription: 'my-subscription'
    Destination: 'AzureVMs'
    storage: 'my-storage'
    resourceGroup: 'my-rg'
    vmsAdminUserName: $(VMS_USER)
    vmsAdminPassword: $(VMS_PASS)

Odwoływanie się do zmiennych wpisów tajnych w grupach zmiennych

W tym przykładzie pokazano, jak odwoływać się do grupy zmiennych w pliku YAML, a także dodawać zmienne w pliku YAML. Istnieją dwie zmienne używane z grupy zmiennych: user i token. Zmienna token jest wpisem tajnym i jest mapowana na zmienną środowiskową $env:MY_MAPPED_TOKEN , aby można było do niej odwoływać się w języku YAML.

Ten kod YAML wykonuje wywołanie REST w celu pobrania listy wydań i zwraca wynik.

variables: 
- group: 'my-var-group' # variable group
- name: 'devopsAccount' # new variable defined in YAML
  value: 'contoso'
- name: 'projectName' # new variable defined in YAML
  value: 'contosoads'

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
        # Encode the Personal Access Token (PAT)
        # $env:USER is a normal variable in the variable group
        # $env:MY_MAPPED_TOKEN is a mapped secret variable
        $base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $env:USER,$env:MY_MAPPED_TOKEN)))

        # Get a list of releases
        $uri = "https://vsrm.dev.azure.com/$(devopsAccount)/$(projectName)/_apis/release/releases?api-version=5.1"

        # Invoke the REST call
        $result = Invoke-RestMethod -Uri $uri -Method Get -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}

        # Output releases in JSON
        Write-Host $result.value
  env:
    MY_MAPPED_TOKEN: $(token) # Maps the secret variable $(token) from my-var-group

Ważne

Domyślnie w przypadku repozytoriów GitHub zmienne tajne skojarzone z potokiem nie są udostępniane kompilacjom rozwidlenia żądań ściągnięcia. Aby uzyskać więcej informacji, zobacz Contributions from forks (Współtworzenie z rozwidleń).

Kod YAML nie jest obsługiwany w programie TFS.

Udostępnianie zmiennych między potokami

Aby udostępnić zmienne w wielu potokach w projekcie, użyj interfejsu internetowego. W obszarze Biblioteka użyj grup zmiennych.

Używanie zmiennych wyjściowych z zadań

Niektóre zadania definiują zmienne wyjściowe, które można używać w krokach podrzędnych, zadaniach i etapach. W języku YAML można uzyskiwać dostęp do zmiennych między zadaniami i etapami przy użyciu zależności.

Niektóre zadania definiują zmienne wyjściowe, które można używać w krokach podrzędnych i zadaniach w ramach tego samego etapu. W języku YAML można uzyskiwać dostęp do zmiennych między zadaniami przy użyciu zależności.

Niektóre zadania definiują zmienne wyjściowe, które można używać w krokach podrzędnych w ramach tego samego zadania.

  • Aby odwołać się do zmiennej z innego zadania w ramach tego samego zadania, użyj polecenia TASK.VARIABLE.
  • Aby odwołać się do zmiennej z zadania z innego zadania, użyj polecenia dependencies.JOB.outputs['TASK.VARIABLE'].

Uwaga

Domyślnie każdy etap w potoku zależy od etapu tuż przed nim w pliku YAML. Jeśli musisz odwołać się do etapu, który nie jest bezpośrednio przed bieżącym, możesz przesłonić tę automatyczną wartość domyślną, dodając sekcję dependsOn do etapu.

Uwaga

W poniższych przykładach użyto standardowej składni potoku. Jeśli używasz potoków wdrażania, składnia zmiennych i zmiennych warunkowych będzie się różnić. Aby uzyskać informacje o konkretnej składni do użycia, zobacz Deployment jobs (Zadania wdrażania).

W tych przykładach założono, że mamy zadanie o nazwie MyTask, które ustawia zmienną wyjściową o nazwie MyVar. Dowiedz się więcej o składni w temacie Wyrażenia — zależności.

Użyj danych wyjściowych w tym samym zadaniu

steps:
- task: MyTask@1  # this step generates the output variable
  name: ProduceVar  # because we're going to depend on it, we need to name the step
- script: echo $(ProduceVar.MyVar) # this step uses the output variable

Używanie danych wyjściowych w innym zadaniu

jobs:
- job: A
  steps:
  # assume that MyTask generates an output variable called "MyVar"
  # (you would learn that from the task's documentation)
  - task: MyTask@1
    name: ProduceVar  # because we're going to depend on it, we need to name the step
- job: B
  dependsOn: A
  variables:
    # map the output variable from A into this job
    varFromA: $[ dependencies.A.outputs['ProduceVar.MyVar'] ]
  steps:
  - script: echo $(varFromA) # this step uses the mapped-in variable

Używanie danych wyjściowych na innym etapie

Aby użyć danych wyjściowych z innego etapu na poziomie zadania, należy użyć stageDependencies składni:

  • Na poziomie etapu format odwoływania się do zmiennych z innego etapu to dependencies.STAGE.outputs['JOB.TASK.VARIABLE']
  • Na poziomie zadania format odwoływania się do zmiennych z innego etapu to stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE']
stages:
- stage: One
  jobs:
  - job: A
    steps:
    - task: MyTask@1  # this step generates the output variable
      name: ProduceVar  # because we're going to depend on it, we need to name the step
- stage: Two
  jobs:
  - job: B
    variables:
      # map the output variable from A into this job
      varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
    steps:
    - script: echo $(varFromA) # this step uses the mapped-in variable

Można również przekazywać zmienne między etapami przy użyciu danych wejściowych pliku. W tym celu należy zdefiniować zmienne na drugim etapie na poziomie zadania, a następnie przekazać zmienne jako env: dane wejściowe.

## script-a.sh
echo "##vso[task.setvariable variable=sauce;isOutput=true]crushed tomatoes"

## script-b.sh
echo 'Hello file version'
echo $skipMe
echo $StageSauce

## azure-pipelines.yml
stages:

- stage: one
  jobs:
  - job: A
    steps:
    - task: Bash@3
      inputs:
          filePath: 'script-a.sh'
      name: setvar
    - bash: |
       echo "##vso[task.setvariable variable=skipsubsequent;isOutput=true]true"
      name: skipstep

- stage: two
  jobs:
  - job: B
    variables:
      - name: StageSauce
        value: $[ stageDependencies.one.A.outputs['setvar.sauce'] ]
      - name: skipMe
        value: $[ stageDependencies.one.A.outputs['skipstep.skipsubsequent'] ]
    steps:
    - task: Bash@3
      inputs:
        filePath: 'script-b.sh'
      name: fileversion
      env:
        StageSauce: $(StageSauce) # predefined in variables section
        skipMe: $(skipMe) # predefined in variables section
    - task: Bash@3
      inputs:
        targetType: 'inline'
        script: |
          echo 'Hello inline version'
          echo $(skipMe) 
          echo $(StageSauce)

Dane wyjściowe z etapów w poprzednim potoku wyglądają następująco:

Hello inline version
true
crushed tomatoes

Lista zmiennych

Możesz wyświetlić listę wszystkich zmiennych w potoku za pomocą polecenia az pipelines variable list . Aby rozpocząć pracę, zobacz Wprowadzenie za pomocą interfejsu wiersza polecenia platformy Azure DevOps.

az pipelines variable list [--org]
                           [--pipeline-id]
                           [--pipeline-name]
                           [--project]

Parametry

  • org: Azure DevOps adres URL organizacji. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli wartość domyślna nie jest skonfigurowana lub wybrana przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-id: wymagane, jeśli nie podano nazwy potoku . Identyfikator potoku.
  • nazwa-potoku: wymagane, jeśli nie podano identyfikatora potoku , ale ignorowane, jeśli podano identyfikator potoku . Nazwa potoku.
  • projekt: nazwa lub identyfikator projektu. Projekt domyślny można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli ustawienie nie zostało skonfigurowane jako domyślne lub pobrane przy użyciu polecenia git config.

Przykład

Poniższe polecenie wyświetla listę wszystkich zmiennych w potoku o identyfikatorze 12 i pokazuje wynik w formacie tabeli.

az pipelines variable list --pipeline-id 12 --output table

Name           Allow Override    Is Secret    Value
-------------  ----------------  -----------  ------------
MyVariable     False             False        platform
NextVariable   False             True         platform
Configuration  False             False        config.debug

Ustawianie zmiennych w skryptach

Skrypt w potoku może zdefiniować zmienną, aby mogła być zużywana przez jeden z kolejnych kroków potoku. Wszystkie zmienne ustawione przez tę metodę są traktowane jako ciągi. Aby ustawić zmienną ze skryptu, należy użyć składni polecenia i wydrukować w pliku stdout.

Ustawianie zmiennej o zakresie zadania na podstawie skryptu

Aby ustawić zmienną ze skryptu, należy użyć polecenia rejestrowaniatask.setvariable. Spowoduje to zaktualizowanie zmiennych środowiskowych dla kolejnych zadań. Kolejne zadania będą miały dostęp do nowej zmiennej ze składnią makr i w zadaniach jako zmiennych środowiskowych.

Po issecret ustawieniu wartości true wartość zmiennej zostanie zapisana jako wpis tajny i zamaskowana z dziennika. Aby uzyskać więcej informacji na temat zmiennych tajnych, zobacz polecenia rejestrowania.

steps:
# Create a variable
- bash: |
    echo "##vso[task.setvariable variable=sauce]crushed tomatoes" # remember to use double quotes

# Use the variable
# "$(sauce)" is replaced by the contents of the `sauce` variable by Azure Pipelines
# before handing the body of the script to the shell.
- bash: |
    echo my pipeline variable is $(sauce)

Kolejne kroki będą również zawierać zmienną potoku dodaną do środowiska. Nie można użyć zmiennej w kroku, który jest zdefiniowany.

steps:
# Create a variable
# Note that this does not update the environment of the current script.
- bash: |
    echo "##vso[task.setvariable variable=sauce]crushed tomatoes"

# An environment variable called `SAUCE` has been added to all downstream steps
- bash: |
    echo "my environment variable is $SAUCE"
- pwsh: |
    Write-Host "my environment variable is $env:SAUCE"

Dane wyjściowe z poprzedniego potoku.

my environment variable is crushed tomatoes
my environment variable is crushed tomatoes

Ustawianie zmiennej wyjściowej z wieloma zadaniami

Jeśli chcesz udostępnić zmienną dla przyszłych zadań, musisz oznaczyć ją jako zmienną wyjściową przy użyciu polecenia isOutput=true. Następnie możesz zamapować go na przyszłe zadania przy użyciu $[] składni i wraz z nazwą kroku, która ustawiła zmienną. Zmienne wyjściowe z wieloma zadaniami działają tylko dla zadań na tym samym etapie.

Aby przekazać zmienne do zadań na różnych etapach, użyj składni zależności etapu .

Uwaga

Domyślnie każdy etap w potoku zależy od etapu tuż przed nim w pliku YAML. W związku z tym każdy etap może używać zmiennych wyjściowych z poprzedniego etapu. Aby uzyskać dostęp do dalszych etapów, musisz zmienić graf zależności, na przykład jeśli etap 3 wymaga zmiennej z etapu 1, należy zadeklarować jawną zależność od etapu 1.

Podczas tworzenia zmiennej wyjściowej z wieloma zadaniami należy przypisać wyrażenie do zmiennej. W tym pliku YAML $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] jest przypisywany do zmiennej $(myVarFromJobA).

jobs:
# Set an output variable from job A
- job: A
  pool:
    vmImage: 'windows-latest'
  steps:
  - powershell: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the value"
    name: setvarStep
  - script: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable into job B
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-18.04'
  variables:
    myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ]  # map in the variable
                                                                          # remember, expressions require single quotes
  steps:
  - script: echo $(myVarFromJobA)
    name: echovar

Dane wyjściowe z poprzedniego potoku.

this is the value
this is the value

Jeśli ustawiasz zmienną z jednego etapu na inny, użyj polecenia stageDependencies.

stages:
- stage: A
  jobs:
  - job: A1
    steps:
     - bash: echo "##vso[task.setvariable variable=myStageOutputVar;isOutput=true]this is a stage output var"
       name: printvar

- stage: B
  dependsOn: A
  variables:
    myVarfromStageA: $[ stageDependencies.A.A1.outputs['printvar.myStageOutputVar'] ]
  jobs:
  - job: B1
    steps:
    - script: echo $(myVarfromStageA)

Jeśli ustawiasz zmienną z macierzy lub wycinka, aby odwołać się do zmiennej podczas uzyskiwania dostępu do niej z zadania podrzędnego, musisz uwzględnić następujące elementy:

  • Nazwa zadania.
  • Krok.
jobs:

# Set an output variable from a job with a matrix
- job: A
  pool:
    vmImage: 'ubuntu-18.04'
  strategy:
    maxParallel: 2
    matrix:
      debugJob:
        configuration: debug
        platform: x64
      releaseJob:
        configuration: release
        platform: x64
  steps:
  - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the $(configuration) value"
    name: setvarStep
  - bash: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable from the debug job
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-18.04'
  variables:
    myVarFromJobADebug: $[ dependencies.A.outputs['debugJob.setvarStep.myOutputVar'] ]
  steps:
  - script: echo $(myVarFromJobADebug)
    name: echovar

jobs:

# Set an output variable from a job with slicing
- job: A
  pool:
    vmImage: 'ubuntu-18.04'
    parallel: 2 # Two slices
  steps:
  - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the slice $(system.jobPositionInPhase) value"
    name: setvarStep
  - script: echo $(setvarStep.myOutputVar)
    name: echovar

# Map the variable from the job for the first slice
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-18.04'
  variables:
    myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromJobsA1)"
    name: echovar

Pamiętaj o prefiksie nazwy zadania do zmiennych wyjściowych zadania wdrożenia . W takim przypadku nazwa zadania to A:

jobs:

# Set an output variable from a deployment
- deployment: A
  pool:
    vmImage: 'ubuntu-18.04'
  environment: staging
  strategy:
    runOnce:
      deploy:
        steps:
        - bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
          name: setvarStep
        - bash: echo $(setvarStep.myOutputVar)
          name: echovar

# Map the variable from the job for the first slice
- job: B
  dependsOn: A
  pool:
    vmImage: 'ubuntu-18.04'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - bash: "echo $(myVarFromDeploymentJob)"
    name: echovar

Kod YAML nie jest obsługiwany w programie TFS.

Ustawianie zmiennych przy użyciu wyrażeń

Zmienną można ustawić przy użyciu wyrażenia. Napotkaliśmy już jeden przypadek, aby ustawić zmienną na dane wyjściowe innego z poprzedniego zadania.

- job: B
  dependsOn: A
  variables:
    myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ] # remember to use single quotes

Do ustawiania zmiennej można użyć dowolnego z obsługiwanych wyrażeń. Oto przykład ustawienia zmiennej, która będzie działać jako licznik rozpoczynający się od 100, zwiększa się o 1 dla każdego przebiegu i jest resetowany do 100 każdego dnia.

jobs:
- job:
  variables:
    a: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 100)]
  steps:
  - bash: echo $(a)

Aby uzyskać więcej informacji na temat liczników, zależności i innych wyrażeń, zobacz wyrażenia.

Kod YAML nie jest obsługiwany w programie TFS.

Konfigurowanie zmiennych settable dla kroków

Można zdefiniować settableVariables w ramach kroku lub określić, że nie można ustawić żadnych zmiennych.

W tym przykładzie skrypt nie może ustawić zmiennej.

steps:
- script: echo This is a step
  target:
    settableVariables: none

W tym przykładzie skrypt zezwala na zmienną sauce , ale nie zmienną secretSauce. Na stronie uruchamiania potoku zostanie wyświetlone ostrzeżenie.

Warning that you cannot set secretSauce. 

steps:
  - bash: |
      echo "##vso[task.setvariable variable=Sauce;]crushed tomatoes"
      echo "##vso[task.setvariable variable=secretSauce;]crushed tomatoes with garlic"
    target:
     settableVariables:
      - sauce
    name: SetVars
  - bash: 
      echo "Sauce is $(sauce)"
      echo "secretSauce is $(secretSauce)"
    name: OutputVars

Zezwalaj w czasie kolejki

Jeśli zmienna pojawi się w variables bloku pliku YAML, jej wartość jest stała i nie można jej zastąpić w czasie kolejki. Najlepszym rozwiązaniem jest zdefiniowanie zmiennych w pliku YAML, ale czasami nie ma to sensu. Możesz na przykład zdefiniować zmienną wpisu tajnego i nie udostępnić zmiennej w języku YAML. Może być też konieczne ręczne ustawienie wartości zmiennej podczas uruchamiania potoku.

Dostępne są dwie opcje definiowania wartości czasu kolejki. Możesz zdefiniować zmienną w interfejsie użytkownika i wybrać opcję Zezwalaj użytkownikom na zastąpienie tej wartości podczas uruchamiania tego potoku lub zamiast tego możesz użyć parametrów środowiska uruchomieniowego . Jeśli zmienna nie jest wpisem tajnym, najlepszym rozwiązaniem jest użycie parametrów środowiska uruchomieniowego.

Aby ustawić zmienną w czasie kolejki, dodaj nową zmienną w potoku i wybierz opcję przesłonięcia.

Set a variable at queue time.

Aby zezwolić na ustawianie zmiennej w czasie kolejki, upewnij się, że zmienna nie jest również wyświetlana w variables bloku potoku lub zadania. Jeśli zdefiniujesz zmienną zarówno w bloku zmiennych YAML, jak i w interfejsie użytkownika, wartość w yaML będzie miała priorytet.

Kod YAML nie jest obsługiwany w programie TFS.

Rozszerzanie zmiennych

Po ustawieniu zmiennej o tej samej nazwie w wielu zakresach pierwszeństwo ma zastosowanie następujące pierwszeństwo (pierwszeństwo najwyższe).

  1. Zmienna poziomu zadania ustawiona w pliku YAML
  2. Zmienna poziomu etapu ustawiona w pliku YAML
  3. Zmienna poziomu potoku ustawiona w pliku YAML
  4. Zmienna ustawiona w czasie kolejki
  5. Zmienna potoku ustawiona w interfejsie użytkownika ustawień potoku

W poniższym przykładzie ta sama zmienna a jest ustawiana na poziomie potoku i na poziomie zadania w pliku YAML. Jest ona również ustawiana w grupie Gzmiennych i jako zmienna w interfejsie użytkownika ustawień potoku.

variables:
  a: 'pipeline yaml'

stages:
- stage: one
  displayName: one
  variables:
  - name: a
    value: 'stage yaml'

  jobs:
  - job: A
    variables:
    - name: a
      value: 'job yaml'
    steps:
    - bash: echo $(a)        # This will be 'job yaml'

Jeśli ustawisz zmienną o tej samej nazwie w tym samym zakresie, pierwszeństwo będzie mieć ostatnia ustawiona wartość.

stages:
- stage: one
  displayName: Stage One
  variables: 
    - name: a
      value: alpha
    - name: a
      value: beta
  jobs: 
  - job: I
    displayName: Job I
    variables:
      - name: b
        value: uno
      - name: b
        value: dos
    steps: 
    - script: echo $(a) #outputs beta
    - script: echo $(b) #outputs dos

Uwaga

Jeśli ustawisz zmienną w pliku YAML, nie zdefiniuj jej w edytorze internetowym jako ustawianą w czasie kolejki. Obecnie nie można zmieniać zmiennych ustawionych w pliku YAML w czasie kolejki. Jeśli chcesz ustawić zmienną w czasie kolejki, nie ustawiaj jej w pliku YAML.

Zmienne są rozszerzane raz po uruchomieniu przebiegu i ponownie na początku każdego kroku. Na przykład:

jobs:
- job: A
  variables:
    a: 10
  steps:
  - bash: |
      echo $(a)            # This will be 10
      echo '##vso[task.setvariable variable=a]20'
      echo $(a)            # This will also be 10, since the expansion of $(a) happens before the step
  - bash: echo $(a)        # This will be 20, since the variables are expanded just before the step

W poprzednim przykładzie przedstawiono dwa kroki. Rozszerzanie $(a) zadania odbywa się raz na początku zadania, a raz na początku każdego z tych dwóch kroków.

Ponieważ zmienne są rozwinięte na początku zadania, nie można ich używać w strategii. W poniższym przykładzie nie można użyć zmiennej a do rozwinięcia macierzy zadań, ponieważ zmienna jest dostępna tylko na początku każdego rozwiniętego zadania.

jobs:
- job: A
  variables:
    a: 10
  strategy:
    matrix:
      x:
        some_variable: $(a)    # This does not work

Jeśli zmienna a jest zmienną wyjściową z poprzedniego zadania, możesz użyć jej w przyszłym zadaniu.

- job: A
  steps:
  - powershell: echo "##vso[task.setvariable variable=a;isOutput=true]10"
    name: a_step

# Map the variable into job B
- job: B
  dependsOn: A
  variables:
    some_variable: $[ dependencies.A.outputs['a_step.a'] ]

Rozszerzanie cykliczne

W agencie zmienne, do których odwołuje się $( ) składnia, są rekursywnie rozwinięte. Na przykład:

variables:
  myInner: someValue
  myOuter: $(myInner)

steps:
- script: echo $(myOuter)  # prints "someValue"
  displayName: Variable is $(myOuter)  # display name is "Variable is someValue"

Kod YAML nie jest obsługiwany w programie TFS.