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

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

  • Статья

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

Синтаксис Пример Когда она обрабатывается? Где он расширяется в определении конвейера? Как отображается, если не найден?
макро $(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@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 можно получить доступ к переменным между заданиями и этапами с помощью зависимостей.

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

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