Поделиться через

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

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.

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

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 нет.

Синтаксис Пример Когда она обрабатывается? Где происходит расширение в определении конвейерного процесса? Как отображается, когда не найден?
макрос $(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. Найдите Переменные для этого конвейера.
  3. Добавьте или обновите переменную.
  4. Выберите опцию Хранить это значение в секрете, чтобы переменная сохранялась зашифрованным образом.
  5. Сохраните конвейер.

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

Внимание

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

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

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

В следующем примере показано, как отобразить и использовать секретную переменную, названную mySecret в скриптах PowerShell и Bash. Определены две глобальные переменные. GLOBAL_MYSECRETприсваивается значение секретной переменной и mySecret присваивается значение несекретной переменной.GLOBAL_MY_MAPPED_ENV_VARnonSecretVariable В отличие от обычной переменной конвейера, не существует переменной среды с именем 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@6
  inputs:
    SourcePath: 'my/path' # Specify the source path
    azureSubscription: 'my-subscription' # Azure subscription name
    Destination: 'AzureVMs' # Destination type
    storage: 'my-storage' # Azure storage account name
    resourceGroup: 'my-resource-group' # Resource group name
    vmsAdminUserName: $(VMS_USER) # Admin username for the VM
    vmsAdminPassword: $(VMS_PASS) # Admin password for the VM
    CleanTargetBeforeCopy: false # Do not clean the target before copying

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

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

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

  • Чтобы ссылаться на переменную из другой задачи в одном задании, используйте 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"