Бөлісу құралы:

Определение переменных

  • Мақала

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Переменные — это удобный способ вставки ключевых фрагментов данных в разные части конвейера. Чаще всего переменные используются для определения значения, которое затем можно использовать в конвейере. Все переменные представлены строками и являются изменяемыми. Значение переменной может меняться от выполнения к выполнению или от задания к заданию конвейера.

При определении одной и той же переменной в нескольких местах с одинаковым именем самая локальная переменная имеет приоритет. Таким образом, переменная, определенная на уровне задания, может переопределить набор переменных на уровне этапа. Переменная, определенная на уровне этапа, переопределяет набор переменных на корневом уровне конвейера. Переменная, установленная на корневом уровне конвейера, переопределяет переменную в пользовательском интерфейсе параметров конвейера. Дополнительные сведения о работе с переменными, определенными на уровне задания, этапа и корневого уровня, см . в разделе "Область переменных".

Переменные можно использовать с выражениями для условного назначения значений и дальнейшей настройки конвейеров.

Переменные отличаются от параметров среды выполнения. Параметры среды выполнения являются типизированными. Они доступны во время синтаксического анализа шаблона.

Определяемые пользователем переменные

При определении переменной можно использовать различные синтаксисы (макрос, выражение шаблона или среда выполнения) и используемый синтаксис определяет, где в конвейере отрисовывается переменная.

В конвейерах YAML можно задать переменные на корневом, стадии и уровне заданий. Можно также указать переменные за пределами конвейера YAML в пользовательском интерфейсе. При установке переменной в пользовательском интерфейсе эта переменная может быть зашифрована и задана как секрет.

Определяемые пользователем переменные можно задать как доступные только для чтения. Существуют ограничения именования переменных (например, нельзя использовать secret в начале имени переменной).

С помощью группы переменных можно сделать переменные доступными в нескольких конвейерах.

Используйте шаблоны для определения переменных в одном файле, который используется в нескольких конвейерах.

Определяемые пользователем многострочный переменные

Azure DevOps поддерживает многострочный переменные, но есть несколько ограничений.

Подчиненные компоненты, такие как задачи конвейера, могут неправильно обрабатывать значения переменных.

Azure DevOps не изменяет пользовательские значения переменных. Перед передачей в виде многостроковых переменных необходимо правильно отформатировать значения переменных. При форматировании переменной избегайте специальных символов, не используйте ограниченные имена и убедитесь, что вы используете конец строки формат, который работает для операционной системы агента.

Переменные с несколькими строками ведут себя по-разному в зависимости от операционной системы. Чтобы избежать этого, убедитесь, что для целевой операционной системы правильно форматировать многострочный переменные.

Azure DevOps никогда не изменяет значения переменных, даже если вы предоставляете неподдерживаемое форматирование.

Системные переменные

Помимо определяемых пользователем переменных Azure Pipelines имеет системные переменные с предопределенными значениями. Например, предопределенная переменная Build.BuildId предоставляет идентификатор каждой сборки и может использоваться для идентификации различных запусков конвейера. Переменную можно использовать Build.BuildId в сценариях или задачах, если требуется уникальное значение.

Если вы используете yamL или классические конвейеры сборки, ознакомьтесь с предопределенными переменными для комплексного списка системных переменных.

Если вы используете классические конвейеры выпуска, см . переменные выпуска.

Системные переменные задаются с текущим значением при запуске конвейера. Некоторые переменные задаются автоматически. Как автор конвейера или конечный пользователь, вы изменяете значение системной переменной перед запуском конвейера.

Системные переменные доступны только для чтения.

Переменные среды

Переменные среды зависят от используемой операционной системы. Они внедряются в конвейер с учетом платформы. Формат соответствует формату переменных среды для конкретной платформы сценариев.

В системах UNIX (macOS и Linux) переменные среды имеют формат $NAME. В Windows формат предназначен %NAME% для пакетной службы и $env:NAME в PowerShell.

Системные и пользовательские переменные также внедряются в качестве переменных среды для вашей платформы. Когда переменные преобразуются в переменные среды, имена переменных становятся верхним регистром, а периоды преобразуются в знак подчеркивания. Например, имя any.variable переменной становится именем $ANY_VARIABLEпеременной.

Существуют ограничения именования переменных для переменных среды (например, нельзя использовать secret в начале имени переменной).

Ограничения именования переменных

Определяемые пользователем переменные и переменные среды могут состоять из букв, чисел .и _ символов. Не используйте префиксы переменных, зарезервированные системой. Это: endpoint, , inputsecret, pathи securefile. Любая переменная, начинающаяся с одной из этих строк (независимо от прописной буквы), не будет доступна вашим задачам и сценариям.

Общие сведения о синтаксисе переменной

Azure Pipelines поддерживает три разных способа добавления ссылок на переменные: макрос, выражение шаблона и выражение среды выполнения. Для разных целей можно использовать каждый синтаксис, и каждый из них имеет некоторые ограничения.

В конвейере переменные выражения шаблона (${{ variables.var }}) обрабатываются во время компиляции до запуска среды выполнения. Переменные синтаксиса макросов ($(var)) обрабатываются во время выполнения перед выполнением задачи. Выражения среды выполнения ($[variables.var]) также обрабатываются во время выполнения, но предназначены для использования с условиями и выражениями. Когда вы используете выражение среды выполнения, оно должно занимать всю правую часть определения.

В этом примере вы увидите, что выражение шаблона по-прежнему имеет начальное значение переменной после обновления переменной. Значение переменной синтаксиса макросов обновляется. Значение выражения шаблона не изменяется, так как все переменные выражения шаблона обрабатываются во время компиляции перед выполнением задач. Напротив, переменные синтаксиса макросов оцениваются перед выполнением каждой задачи.

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

Переменные синтаксиса макросов

В большинстве примеров документации используется синтаксис макросов ($(var)). Синтаксис макросов предназначен для интерполяции значений переменных в входные данные задач и в другие переменные.

Переменные с синтаксисом макросов обрабатываются перед выполнением задачи во время выполнения. Среда выполнения происходит после расширения шаблона. При обнаружении макросов система заменяет выражение содержимым переменной. Если эта переменная отсутствует по имени, то выражение макроса не изменяется. Например, если $(var) не удается заменить, $(var) не будет заменено ничего.

Переменные синтаксиса макросов остаются неизменными без значения, так как пустое значение $() может означать что-то для выполняемой задачи, и агент не должен предполагать, что это значение заменено. Например, если вы используете $(foo) для ссылки на переменную foo в задаче Bash, замена всех $() выражений во входных данных задаче может нарушить скрипты Bash.

Переменные макросов развертываются только в том случае, если они используются для значения, а не в качестве ключевого слова. Значения отображаются справа от определения конвейера. Ниже приведено допустимое значение: key: $(value) Недействителен следующий параметр: $(key): value Переменные макросов не развертываются при отображении имени задания. Вместо этого необходимо использовать displayName свойство.

Примечание.

Переменные синтаксиса макросов развернуты только для stages, jobsи steps. Например, нельзя использовать синтаксис макросов resource внутри или trigger.

В этом примере используется синтаксис макросов с Bash, PowerShell и задачей скрипта. Синтаксис вызова переменной с синтаксисом макросов одинаков для всех трех.

variables:
 - name: projectName
   value: contoso

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

Синтаксис выражения шаблона

Для расширения параметров шаблона и переменных (${{ variables.var }}) можно использовать синтаксис выражения шаблона. Процесс переменных шаблона во время компиляции и замена перед запуском среды выполнения. Выражения шаблонов предназначены для повторного использования частей YAML в качестве шаблонов.

Переменные шаблона автоматически объединяется с пустыми строками, если значение замены не найдено. Выражения шаблона, в отличие от макросов и выражений среды выполнения, могут отображаться как ключи (левая сторона) или значения (справа). Ниже приведено допустимое значение: ${{ variables.key }} : ${{ variables.value }}

Синтаксис выражения среды выполнения

Вы можете использовать синтаксис выражения среды выполнения для переменных, развернутых во время выполнения ($[variables.var]). Переменные выражения среды выполнения автоматически объединяется с пустыми строками, если значение замены не найдено. Используйте выражения среды выполнения в условиях задания, для поддержки условного выполнения заданий или целых этапов.

Переменные выражения среды выполнения развертываются только в том случае, если они используются для значения, а не в качестве ключевого слова. Значения отображаются справа от определения конвейера. Ниже приведено допустимое значение: key: $[variables.value] Недействителен следующий параметр: $[variables.key]: value Выражение среды выполнения должно занять всю правую сторону пары "ключ-значение". Например, допустимо, key: $[variables.value] но key: $[variables.value] foo не является.

Синтаксис Пример Когда она обрабатывается? Где он расширяется в определении конвейера? Как он отрисовывается, когда он не найден?
macro $(var) среда выполнения перед выполнением задачи значение (справа) Отпечатки $(var)
выражение шаблона ${{ variables.var }} время компиляции ключ или значение (слева или справа) пустая строка
Выражение среды выполнения $[variables.var] среда выполнения значение (справа) пустая строка

Какой синтаксис следует использовать?

Используйте синтаксис макросов, если вы предоставляете безопасную строку или предопределенные входные данные переменной для задачи.

Выберите выражение среды выполнения, если вы работаете с условиями и выражениями. Однако не используйте выражение среды выполнения, если не хотите, чтобы пустая переменная печатала (например: $[variables.var]). Например, если у вас есть условная логика, которая зависит от переменной, имеющей определенное значение или нет значения. В этом случае следует использовать макросовое выражение.

Обычно переменная шаблона является стандартной для использования. Используя переменные шаблона, конвейер полностью внедряет значение переменной в конвейер при компиляции конвейера. Это полезно при попытке отладки конвейеров. Вы можете скачать файлы журнала и оценить полностью развернутое значение, которое будет заменено. Так как переменная заменена, не следует использовать синтаксис шаблона для конфиденциальных значений.

Задание переменных в конвейере

В большинстве случаев переменные задаются и используются в YAML-файле. Это позволяет отслеживать изменения переменной в системе управления версиями. Вы также можете определить переменные в пользовательском интерфейсе параметров конвейера (см. классическую вкладку) и ссылаться на них в YAML.

Ниже приведен пример, показывающий, как задать две переменные и configuration platformиспользовать их позже. Чтобы использовать переменную в инструкции YAML, заключите ее в $()оболочку. Переменные нельзя использовать для определения repository в инструкции 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)

Области действия переменных

В YAML-файле можно задать переменную в различных областях:

  • На корневом уровне, чтобы сделать его доступным для всех заданий в конвейере.
  • На уровне этапа, чтобы сделать его доступным только для определенного этапа.
  • На уровне задания, чтобы сделать его доступным только для определенного задания.

При определении переменной в верхней части YAML переменная доступна для всех заданий и этапов конвейера и является глобальной переменной. Глобальные переменные, определенные в YAML, не отображаются в пользовательском интерфейсе параметров конвейера.

Переменные на уровне задания переопределяют переменные на корневом и промежуточном уровне. Переменные на уровне этапа переопределяют переменные на корневом уровне.

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

Выходные данные обоих заданий выглядят следующим образом:

# job1
value 
value1
value1

# job2
value
value2
value

Указание переменных

В предыдущих примерах variables ключевое слово следует списку пар "ключ-значение". Ключи — это имена переменных, а значения — это значения переменных.

Существует еще один синтаксис, который полезен, если вы хотите использовать шаблоны для переменных или групп переменных.

С помощью шаблонов переменные можно определить в одном YAML и включить в другой файл YAML.

Группы переменных — это набор переменных, которые можно использовать в нескольких конвейерах. Они позволяют управлять и упорядочивать переменные, которые являются общими для различных этапов в одном месте.

Используйте этот синтаксис для шаблонов переменных и групп переменных на корневом уровне конвейера.

В этом альтернативном синтаксисе variables ключевое слово принимает список описателей переменных. Описатели переменных предназначены name для обычной переменной, group для группы переменных и template для включения шаблона переменной. В следующем примере показаны все три.

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

Дополнительные сведения об повторном использовании переменных с шаблонами.

Доступ к переменным через среду

Обратите внимание, что переменные также становятся доступными для сценариев с помощью переменных среды. Синтаксис для использования этих переменных среды зависит от языка сценариев.

Имя является верхним регистром, а . имя заменяется _на . Это автоматически вставляется в среду процесса. Далее приводятся некоторые примеры.

  • Скрипт пакетной службы: %VARIABLE_NAME%
  • Сценарий PowerShell: $env:VARIABLE_NAME
  • Скрипт Bash: $VARIABLE_NAME

Внимание

Предопределенные переменные, содержащие пути к файлам, преобразуются в соответствующий стиль (стиль Windows C:\foo\ и стиль Unix /foo/) на основе типа узла агента и типа оболочки. Если вы выполняете задачи скрипта bash в Windows, следует использовать метод переменной среды для доступа к этим переменным, а не методу переменной конвейера, чтобы убедиться, что у вас есть правильный путь к файлу.

Определение переменных секрета

Совет

Секретные переменные не экспортируются автоматически в виде переменных среды. Чтобы использовать секретные переменные в скриптах, явно сопоставляйте их с переменными среды. Дополнительные сведения см. в разделе "Задание секретных переменных".

Не устанавливайте секретные переменные в файле YAML. Операционные системы часто регистрируют команды для выполняемых процессов, и вы не хотите, чтобы журнал включал секрет, переданный в качестве входных данных. Используйте среду скрипта или сопоставите переменную в блоке variables , чтобы передать секреты в конвейер.

Примечание.

Azure Pipelines делает попытку маскировать секреты при создании данных в журналы конвейера, поэтому вы можете увидеть дополнительные переменные и данные, маскированные в выходных данных и журналах, которые не заданы как секреты.

Необходимо задать секретные переменные в пользовательском интерфейсе параметров конвейера. Эти переменные относятся к конвейеру, в котором они задаются. Можно также задать секретные переменные в группах переменных.

Чтобы задать секреты в веб-интерфейсе, выполните следующие действия.

  1. Перейдите на страницу Pipelines (Конвейеры), выберите соответствующий конвейер и нажмите кнопку Edit (Изменить).
  2. Найдите Variables (Переменные) для этого конвейера.
  3. Добавьте или обновите переменную.
  4. Выберите параметр сохранить этот секрет значения, чтобы сохранить переменную зашифрованным образом.
  5. Сохраните конвейер.

Секретные переменные шифруются неактивных с помощью 2048-разрядного ключа RSA. Секреты доступны агенту для задач и сценариев, которые будут использоваться. Будьте осторожны с тем, кто имеет доступ к изменению конвейера.

Внимание

Мы делаем попытку маскировать секреты от отображения в выходных данных Azure Pipelines, но вам по-прежнему необходимо принять меры предосторожности. Никогда не повторять секреты в качестве выходных данных. Некоторые аргументы командной строки журнала операционных систем. Никогда не передавать секреты в командной строке. Вместо этого мы рекомендуем сопоставить секреты с переменными среды.

Мы никогда не маскируем подстроки секретов. Если, например, "abc123" задается как секрет, "abc" не маскируется из журналов. Это позволяет избежать маскирования секретов на слишком детальном уровне, что делает журналы нечитаемыми. По этой причине секреты не должны содержать структурированные данные. Если, например, "{ "foo": "bar" }" имеет значение секрета, "панель" не маскируется из журналов.

В отличие от обычной переменной, они не расшифровываются автоматически в переменные среды для скриптов. Необходимо явно сопоставить секретные переменные.

В следующем примере показано, как сопоставить и использовать секретную переменную, вызванную mySecret в сценариях PowerShell и Bash. Определены две глобальные переменные. GLOBAL_MYSECRETприсваивается значение секретной переменной и GLOBAL_MY_MAPPED_ENV_VAR присваивается значение несекретной переменной.mySecretnonSecretVariable В отличие от обычной переменной конвейера, не вызывается MYSECRETпеременная среды.

Задача PowerShell запускает скрипт для печати переменных.

  • $(mySecret): это прямая ссылка на секретную переменную и работает.
  • $env:MYSECRET: эта попытка получить доступ к секретной переменной в качестве переменной среды, которая не работает, так как секретные переменные не сопоставляются автоматически с переменными среды.
  • $env:GLOBAL_MYSECRET: эта попытка получить доступ к секретной переменной через глобальную переменную, которая также не работает, так как секретные переменные невозможно сопоставить таким образом.
  • $env:GLOBAL_MY_MAPPED_ENV_VAR: эта переменная обращается к несекретной переменной через глобальную переменную, которая работает.
  • $env:MY_MAPPED_ENV_VAR: этот метод обращается к секретной переменной через переменную среды для конкретной задачи, которая является рекомендуемой способом сопоставления секретных переменных с переменными среды.
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

Выходные данные обоих задач в предыдущем скрипте будут выглядеть следующим образом:

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: ***

Кроме того, можно использовать секретные переменные вне скриптов. Например, можно сопоставить секретные переменные с задачами с помощью variables определения. В этом примере показано, как использовать секретные переменные $(vmsUser) и $(vmsAdminPass) задачу копирования файлов 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)

Ссылка на секретные переменные в группах переменных

В этом примере показано, как ссылаться на группу переменных в файле YAML, а также как добавлять переменные в YAML. Из группы переменных используются две переменные: user и token. Переменная token является секретом и сопоставляется с переменной $env:MY_MAPPED_TOKEN среды, чтобы ее можно было ссылать в YAML.

Этот YAML вызывает REST для получения списка выпусков и выводит результат.

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

Внимание

По умолчанию с репозиториями GitHub секретные переменные, связанные с конвейером, недоступны для создания сборок запросов на вытягивание вилок. Дополнительные сведения см. в разделе "Вклады из вилок".

Совместное использование переменных между конвейерами

Чтобы совместно использовать переменные в нескольких конвейерах проекта, используйте веб-интерфейс. В разделе "Библиотека" используйте группы переменных.

Использование выходных переменных из задач

Некоторые задачи определяют выходные переменные, которые можно использовать в подчиненных шагах, заданиях и этапах. В YAML можно получить доступ к переменным между заданиями и этапами с помощью зависимостей.

При ссылке на матричные задания в подчиненных задачах необходимо использовать другой синтаксис. См. раздел "Задание выходной переменной с несколькими заданиями". Кроме того, необходимо использовать другой синтаксис для переменных в заданиях развертывания. Сведения о поддержке выходных переменных в заданиях развертывания.

Некоторые задачи определяют выходные переменные, которые можно использовать в подчиненных шагах и заданиях на одном этапе. В YAML можно получить доступ к переменным между заданиями с помощью зависимостей.

  • Чтобы ссылаться на переменную из другой задачи в одном задании, используйте TASK.VARIABLE.
  • Чтобы ссылаться на переменную из задачи из другого задания, используйте dependencies.JOB.outputs['TASK.VARIABLE'].

Примечание.

По умолчанию каждый этап в конвейере зависит от одного непосредственно перед ним в YAML-файле. Если вам нужно ссылаться на этап, который не находится непосредственно перед текущим, можно переопределить этот автоматический параметр по умолчанию, добавив dependsOn раздел на этап.

Примечание.

В следующих примерах используется стандартный синтаксис конвейера. Если вы используете конвейеры развертывания, оба синтаксиса переменных и условной переменной будут отличаться. Сведения об используемом синтаксисе см. в разделе "Задания развертывания".

В этих примерах предполагается, что у нас есть задача MyTask, которая задает выходную переменную MyVar. Дополнительные сведения о синтаксисе в выражениях — зависимости.

Использование выходных данных в одном задании

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

Использование выходных данных в другом задании

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

Использование выходных данных на другом этапе

Для использования выходных данных из другого этапа используется stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE']формат для ссылок переменных. На уровне этапа, но не на уровне задания, эти переменные можно использовать в условиях.

Выходные переменные доступны только на следующем нижнем этапе. Если несколько этапов используют одну выходную переменную, используйте dependsOn условие.

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
  dependsOn:
  - One
  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

- stage: Three
  dependsOn:
  - One
  - Two
  jobs:
  - job: C
    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

Можно также передавать переменные между этапами с помощью входных данных файла. Для этого необходимо определить переменные на втором этапе на уровне задания, а затем передать переменные в качестве env: входных данных.

## 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)

Выходные данные из этапов предыдущего конвейера выглядят следующим образом:

Hello inline version
true
crushed tomatoes

Перечисление переменных

Вы можете перечислить все переменные в конвейере с помощью команды az pipelines variable list . Сведения о начале работы см. в статье "Начало работы с Azure DevOps CLI".

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

Параметры

  • org: URL-адрес организации Azure DevOps. Вы можете настроить организацию по умолчанию с помощью az devops configure -d organization=ORG_URL. Требуется, если не настроено как по умолчанию или выбрано с помощью git config. Пример: --org https://dev.azure.com/MyOrganizationName/.
  • идентификатор конвейера: обязательный, если имя конвейера не задано. Идентификатор конвейера.
  • имя конвейера: обязательный, если идентификатор конвейера не указан, но игнорируется, если задан идентификатор конвейера. Имя конвейера.
  • проект: имя или идентификатор проекта. Вы можете настроить проект по умолчанию с помощью az devops configure -d project=NAME_OR_ID. Требуется, если не настроено как по умолчанию или выбрано с помощью git config.

Пример

Следующая команда содержит список всех переменных в конвейере с идентификатором 12 и отображает результат в формате таблицы.

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

Установка переменных в скриптах

Скрипты могут определять переменные, которые позже используются в последующих шагах в конвейере. Все переменные, заданные этим методом, обрабатываются как строки. Чтобы задать переменную из скрипта, используйте синтаксис команды и распечатайте его в stdout.

Задание переменной с областью действия задания из скрипта

Чтобы задать переменную из скрипта, используйте task.setvariable команду ведения журнала. Это обновляет переменные среды для последующих заданий. Последующие задания имеют доступ к новой переменной с синтаксисом макросов и в задачах в качестве переменных среды.

Если issecret значение равно true, значение переменной будет сохранено в виде секрета и маскировано из журнала. Дополнительные сведения о секретных переменных см . в командах ведения журнала.

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)

Последующие шаги также будут добавлены в среду переменной конвейера. Нельзя использовать переменную на шаге, который он определен.

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"

Выходные данные предыдущего конвейера.

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

Задание выходной переменной с несколькими заданиями

Если вы хотите сделать переменную доступной для будущих заданий, ее необходимо пометить как выходную переменную с помощью isOutput=true. Затем его можно сопоставить с будущими заданиями с помощью синтаксиса $[] и включая имя шага, которое задает переменную. Выходные переменные с несколькими заданиями работают только на одном этапе.

Чтобы передать переменные заданиям на разных этапах, используйте синтаксис зависимостей этапа.

Примечание.

По умолчанию каждый этап в конвейере зависит от одного непосредственно перед ним в YAML-файле. Поэтому каждый этап может использовать выходные переменные из предыдущего этапа. Чтобы получить доступ к дальнейшим этапам, необходимо изменить граф зависимостей, например, если для этапа 3 требуется переменная с этапа 1, необходимо объявить явную зависимость от этапа 1.

При создании выходной переменной с несколькими заданиями следует назначить выражение переменной. В этом YAML $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] присваивается переменной $(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-latest'
  variables:
    myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ]  # map in the variable
                                                                          # remember, expressions require single quotes
  steps:
  - script: echo $(myVarFromJobA)
    name: echovar

Выходные данные предыдущего конвейера.

this is the value
this is the value

Если вы задаете переменную из одной стадии в другую, используйте 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)

Если вы задаете переменную из матрицы или среза, то для ссылки на переменную при доступе к ней из подчиненного задания необходимо включить следующее:

  • Имя задания.
  • Шаг.
jobs:

# Set an output variable from a job with a matrix
- job: A
  pool:
    vmImage: 'ubuntu-latest'
  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-latest'
  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-latest'
    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-latest'
  variables:
    myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
  steps:
  - script: "echo $(myVarFromJobsA1)"
    name: echovar

Обязательно префиксировать имя задания в выходные переменные задания развертывания . В этом случае имя задания :A

jobs:

# Set an output variable from a deployment
- deployment: A
  pool:
    vmImage: 'ubuntu-latest'
  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-latest'
  variables:
    myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
  steps:
  - bash: "echo $(myVarFromDeploymentJob)"
    name: echovar

Задание переменных с помощью выражений

Переменную можно задать с помощью выражения. Мы уже столкнулись с одним из этих случаев, чтобы задать переменную выходным данным другого из предыдущего задания.

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

Для задания переменной можно использовать любое из поддерживаемых выражений. Ниже приведен пример задания переменной для действия в качестве счетчика, который начинается с 100, увеличивается на 1 для каждого запуска и получает сброс до 100 каждый день.

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

Дополнительные сведения о счетчиках, зависимостях и других выражениях см . в разделе "Выражения".

Настройка наборных переменных для шагов

Можно определить на шаге или указать settableVariables , что переменные не могут быть заданы.

В этом примере скрипт не может задать переменную.

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

В этом примере скрипт разрешает переменную sauce , но не переменную secretSauce. На странице запуска конвейера появится предупреждение.

Предупреждение о том, что вы не можете задать 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

Разрешение во время очереди

Если переменная отображается в variables блоке YAML-файла, его значение исправлено и не может быть переопределено во время очереди. Рекомендуется определить переменные в файле YAML, но есть моменты, когда это не имеет смысла. Например, может потребоваться определить секретную переменную и не предоставлять переменную в YAML. Кроме того, может потребоваться вручную задать значение переменной во время выполнения конвейера.

Существует два варианта определения значений времени очереди. Можно определить переменную в пользовательском интерфейсе и выбрать параметр разрешить пользователям переопределить это значение при запуске этого конвейера или использовать параметры среды выполнения. Если переменная не является секретом, рекомендуется использовать параметры среды выполнения.

Чтобы задать переменную во время очереди, добавьте новую переменную в конвейере и выберите параметр переопределения.

Задайте переменную во время очереди.

Чтобы разрешить настройку переменной во время очереди, убедитесь, что переменная также не отображается в variables блоке конвейера или задания. Если вы определяете переменную как в блоке переменных YAML, так и в пользовательском интерфейсе, значение в YAML имеет приоритет.

Расширение переменных

Когда вы устанавливаете переменную с одним и тем же именем в нескольких областях, применяется следующий приоритет (сначала самый высокий приоритет).

  1. Переменная уровня задания, заданная в файле YAML.
  2. Переменная уровня этапа, заданная в файле YAML.
  3. Переменная уровня конвейера, заданная в файле YAML.
  4. Переменная, заданная во время очереди.
  5. Переменная конвейера, заданная в пользовательском интерфейсе параметров конвейера.

В следующем примере та же переменная a устанавливается на уровне конвейера и уровне задания в YAML-файле. Он также устанавливается в группе Gпеременных и в качестве переменной в пользовательском интерфейсе параметров конвейера.

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'

При установке переменной с тем же именем в той же области последнее значение набора имеет приоритет.

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

Примечание.

Если вы задаете переменную в YAML-файле, не определите ее в веб-редакторе в качестве набора во время очереди. В настоящее время нельзя изменять переменные, заданные в ФАЙЛЕ YAML во время очереди. Если необходимо задать переменную во время очереди, не устанавливайте ее в YAML-файле.

Переменные развертываются один раз при запуске и снова в начале каждого шага. Например:

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

В предыдущем примере описано два шага. Расширение $(a) происходит один раз в начале задания, и один раз в начале каждого из двух шагов.

Так как переменные расширяются в начале задания, их нельзя использовать в стратегии. В следующем примере нельзя использовать переменную для расширения матрицы заданий, так как переменная a доступна только в начале каждого развернутого задания.

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

Если переменная a является выходной переменной из предыдущего задания, ее можно использовать в будущем задании.

- 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'] ]

Рекурсивное расширение

В агенте переменные, на которые $( ) ссылается синтаксис, рекурсивно расширяются. Например:

variables:
  myInner: someValue
  myOuter: $(myInner)

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