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

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

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Определяемые пользователем переменные и переменные среды могут состоять из букв, чисел .и _ символов. Не используйте префиксы переменных, зарезервированные системой. Эти префиксы: endpoint, input, secret, 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. Он не расширяет их в ключевых словах конвейера, которые разрешаются во время компиляции, таких как resources, trigger, или ссылочное значение репозитория шага checkout (например, checkout: git://MyProject/MyRepo@$(var) не работает). Чтобы параметризировать эти значения, используйте вместо этого выражения шаблона (${{ }}) или параметры среды выполнения .

В этом примере используется синтаксис макросов с 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] среда выполнения значение (справа) пустая строка

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

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

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

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

Использование ИИ для выявления проблем с синтаксисом переменных

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

What types of Azure DevOps variables are used in this YAML pipeline? Give specific examples.
When does each variable process in the pipeline? 
How will each variable render when not found? 
What stages and jobs will the variables be available for?

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

Copilot работает на основе искусственного интеллекта, поэтому возможны сюрпризы и ошибки. Дополнительные сведения см. в Часто задаваемые вопросы по Copilot.

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

В большинстве случаев задайте переменные и используйте их в файле 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.

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

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

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

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

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

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/.
  • идентификатор конвейера: обязательный, если имя конвейера не задано. Идентификатор конвейера.
  • имя конвейера: обязательный, если идентификатор конвейера не указан, но игнорируется, если задан идентификатор конвейера. Имя конвейера.
  • project: имя или идентификатор проекта. Настройте project по умолчанию с помощью 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команду ведения журнала. Эта команда обновляет переменные среды для последующих заданий. Последующие задания могут получить доступ к новой переменной с помощью синтаксиса macro и использовать задачи в качестве переменных среды.

Если задано 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-файле. Поэтому каждый этап может использовать выходные переменные из предыдущего этапа. Чтобы access дальнейшие этапы, необходимо изменить граф зависимостей, например, если для этапа 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)

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

  • Имя задания.
  • Шаг.
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"
  • Last updated on