Определение переменных
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Переменные — это удобный способ вставки ключевых фрагментов данных в разные части конвейера. Чаще всего переменные используются для определения значения, которое затем можно использовать в конвейере. Все переменные представлены строками и являются изменяемыми. Значение переменной может меняться от выполнения к выполнению или от задания к заданию конвейера.
При определении одной переменной в нескольких местах с одинаковым именем наиболее локально область переменная выигрывает. Таким образом, переменная, определенная на уровне задания, может переопределить набор переменных на уровне этапа. Переменная, определенная на уровне этапа, переопределяет набор переменных на корневом уровне конвейера. Переменная, установленная на корневом уровне конвейера, переопределяет переменную в пользовательском интерфейсе параметров конвейера. Дополнительные сведения о работе с переменными, определенными на задании, этапе и корневом уровне, см. в разделе "Переменная область".
Переменные можно использовать с выражениями для условного назначения значений и дальнейшей настройки конвейеров.
Переменные отличаются от параметров среды выполнения. Параметры среды выполнения являются типизированными. Они доступны во время синтаксического анализа шаблона.
Определяемые пользователем переменные
При определении переменной можно использовать различные синтаксисы (макрос, выражение шаблона или среда выполнения) и используемый синтаксис определяет, где в конвейере отрисовывается переменная.
В конвейерах YAML можно задать переменные на корневом, стадии и уровне заданий. Можно также указать переменные за пределами конвейера YAML в пользовательском интерфейсе. При установке переменной в пользовательском интерфейсе эта переменная может быть зашифрована и задана как секрет.
Определяемые пользователем переменные можно задать как доступные только для чтения. Существуют ограничения именования переменных (например, нельзя использовать secret в начале имени переменной).
С помощью группы переменных можно сделать переменные доступными в нескольких конвейерах.
Используйте шаблоны для определения переменных в одном файле, который используется в нескольких конвейерах.
Определяемые пользователем многострочный переменные
Azure DevOps поддерживает многострочный переменные, но есть несколько ограничений.
Подчиненные компоненты, такие как задачи конвейера, могут неправильно обрабатывать значения переменных.
Azure DevOps не изменяет пользовательские значения переменных. Перед передачей в виде многостроковых переменных необходимо правильно отформатировать значения переменных. При форматировании переменной избегайте специальных символов, не используйте ограниченные имена и убедитесь, что вы используете конец строки формат, который работает для операционной системы агента.
Переменные с несколькими строками ведут себя по-разному в зависимости от операционной системы. Чтобы избежать этого, убедитесь, что для целевой операционной системы правильно форматировать многострочный переменные.
Azure DevOps никогда не изменяет значения переменных, даже если вы предоставляете неподдерживаемое форматирование.
Системные переменные
Помимо определяемых пользователем переменных Azure Pipelines имеет системные переменные с предопределенными значениями. Например, предопределенная переменная Build.BuildId предоставляет идентификатор каждой сборки и может использоваться для идентификации различных запусков конвейера. Переменную можно использовать Build.BuildId в сценариях или задачах, если требуется уникальное значение.
Если вы используете yamL или классические конвейеры сборки, ознакомьтесь с предопределенными переменными для комплексного списка системных переменных.
Если вы используете классические конвейеры выпуска, см . переменные выпуска.
Системные переменные задаются с текущим значением при запуске конвейера. Некоторые переменные задаются автоматически. Как автор конвейера или конечный пользователь, вы изменяете значение системной переменной перед запуском конвейера.
Системные переменные доступны только для чтения.
Переменные среды
Переменные среды зависят от используемой операционной системы. Они внедряются в конвейер с учетом платформы. Формат соответствует формату переменных среды для конкретной платформы сценариев.
В системах UNIX (macOS и Linux) переменные среды имеют формат $NAME. В Windows формат предназначен %NAME% для пакетной службы и $env:NAME в PowerShell.
Системные и пользовательские переменные также внедряются в качестве переменных среды для вашей платформы. Когда переменные преобразуются в переменные среды, имена переменных становятся верхним регистром, а периоды преобразуются в знак подчеркивания. Например, имя any.variable переменной становится именем $ANY_VARIABLEпеременной.
Существуют ограничения именования переменных для переменных среды (например, нельзя использовать secret в начале имени переменной).
Ограничения именования переменных
Определяемые пользователем переменные и переменные среды могут состоять из букв, чисел .и _ символов. Не используйте префиксы переменных, зарезервированные системой. Это: endpoint, , inputsecret, pathи securefile. Любая переменная, начинающаяся с одной из этих строк (независимо от прописной буквы), не будет доступна вашим задачам и сценариям.
Общие сведения о синтаксисе переменной
Azure Pipelines поддерживает три разных способа добавления ссылок на переменные: макрос, выражение шаблона и выражение среды выполнения. Для разных целей можно использовать каждый синтаксис, и каждый из них имеет некоторые ограничения.
В конвейере переменные выражения шаблона (${{ variables.var }}) обрабатываются во время компиляции до запуска среды выполнения. Переменные синтаксиса макросов ($(var)) обрабатываются во время выполнения перед выполнением задачи. Выражения среды выполнения ($[variables.var]) также обрабатываются во время выполнения, но предназначены для использования с условиями и выражениями. Когда вы используете выражение среды выполнения, оно должно занимать всю правую часть определения.
В этом примере вы увидите, что выражение шаблона по-прежнему имеет начальное значение переменной после обновления переменной. Значение переменной синтаксиса макросов обновляется. Значение выражения шаблона не изменяется, так как все переменные выражения шаблона обрабатываются во время компиляции перед выполнением задач. Напротив, переменные синтаксиса макросов оцениваются перед выполнением каждой задачи.
variables:
- name: one
value: initialValue
steps:
- script: |
echo ${{ variables.one }} # outputs initialValue
echo $(one)
displayName: First variable pass
- bash: echo "##vso[task.setvariable variable=one]secondValue"
displayName: Set new variable value
- script: |
echo ${{ variables.one }} # outputs initialValue
echo $(one) # outputs secondValue
displayName: Second variable pass
Переменные синтаксиса макросов
В большинстве примеров документации используется синтаксис макросов ($(var)). Синтаксис макросов предназначен для интерполяции значений переменных в входные данные задач и в другие переменные.
Переменные с синтаксисом макросов обрабатываются перед выполнением задачи во время выполнения. Среда выполнения происходит после расширения шаблона. При обнаружении макросов система заменяет выражение содержимым переменной. Если эта переменная отсутствует по имени, то выражение макроса не изменяется. Например, если $(var) не удается заменить, $(var) не будет заменено ничего.
Переменные синтаксиса макросов остаются неизменными без значения, так как пустое значение $() может означать что-то для выполняемой задачи, и агент не должен предполагать, что это значение заменено. Например, если вы используете $(foo) для ссылки на переменную foo в задаче Bash, замена всех $() выражений во входных данных задаче может нарушить скрипты Bash.
Переменные макросов развертываются только при их использовании для значения, а не как ключевое слово. Значения отображаются справа от определения конвейера. Ниже приведено допустимое значение: key: $(value) Недействителен следующий параметр: $(key): value Переменные макросов не развертываются при отображении имени задания. Вместо этого необходимо использовать displayName свойство.
Примечание.
Переменные синтаксиса макросов развернуты только для stages, jobsи steps.
Например, нельзя использовать синтаксис макросов resource внутри или trigger.
В этом примере используется синтаксис макросов с Bash, PowerShell и задачей скрипта. Синтаксис вызова переменной с синтаксисом макросов одинаков для всех трех.
variables:
- name: projectName
value: contoso
steps:
- bash: echo $(projectName)
- powershell: echo $(projectName)
- script: echo $(projectName)
Синтаксис выражения шаблона
Для расширения параметров шаблона и переменных (${{ variables.var }}) можно использовать синтаксис выражения шаблона. Процесс переменных шаблона во время компиляции и замена перед запуском среды выполнения. Выражения шаблонов предназначены для повторного использования частей YAML в качестве шаблонов.
Переменные шаблона автоматически объединяется с пустыми строками, если значение замены не найдено. Выражения шаблона, в отличие от макросов и выражений среды выполнения, могут отображаться как ключи (левая сторона) или значения (справа). Ниже приведено допустимое значение: ${{ variables.key }} : ${{ variables.value }}
Синтаксис выражения среды выполнения
Вы можете использовать синтаксис выражения среды выполнения для переменных, развернутых во время выполнения ($[variables.var]). Переменные выражения среды выполнения автоматически объединяется с пустыми строками, если значение замены не найдено. Используйте выражения среды выполнения в условиях задания, для поддержки условного выполнения заданий или целых этапов.
Переменные выражения среды выполнения расширяются только в том случае, если они используются для значения, а не в качестве ключевое слово. Значения отображаются справа от определения конвейера. Ниже приведено допустимое значение: key: $[variables.value] Недействителен следующий параметр: $[variables.key]: value Выражение среды выполнения должно занять всю правую сторону пары "ключ-значение". Например, допустимо, key: $[variables.value] но key: $[variables.value] foo не является.
| Синтаксис | Пример | Когда она обрабатывается? | Где он расширяется в определении конвейера? | Как он отрисовывается, когда он не найден? |
|---|---|---|---|---|
| macro | $(var) |
среда выполнения перед выполнением задачи | значение (справа) | Отпечатки $(var) |
| выражение шаблона | ${{ variables.var }} |
время компиляции | ключ или значение (слева или справа) | пустая строка |
| Выражение среды выполнения | $[variables.var] |
среда выполнения | значение (справа) | пустая строка |
Какой синтаксис следует использовать?
Используйте синтаксис макросов, если вы предоставляете входные данные для задачи.
Выберите выражение среды выполнения, если вы работаете с условиями и выражениями. Однако не используйте выражение среды выполнения, если не хотите, чтобы пустая переменная печатала (например: $[variables.var]). Например, если у вас есть условная логика, которая зависит от переменной, имеющей определенное значение или нет значения. В этом случае следует использовать макросовое выражение.
Если вы определяете переменную в шаблоне, используйте выражение шаблона.
Задание переменных в конвейере
В большинстве случаев переменные задаются и используются в YAML-файле. Это позволяет отслеживать изменения переменной в системе управления версиями. Вы также можете определить переменные в пользовательском интерфейсе параметров конвейера (см. классическую вкладку) и ссылаться на них в YAML.
Ниже приведен пример, показывающий, как задать две переменные и configurationplatformиспользовать их позже. Чтобы использовать переменную в инструкции 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 делает попытку маскировать секреты при создании данных в журналы конвейера, поэтому вы можете увидеть дополнительные переменные и данные, маскированные в выходных данных и журналах, которые не заданы как секреты.
Необходимо задать секретные переменные в пользовательском интерфейсе параметров конвейера. Эти переменные область в конвейер, в котором они заданы. Можно также задать секретные переменные в группах переменных.
Чтобы задать секреты в веб-интерфейсе, выполните следующие действия.
- Перейдите на страницу Pipelines (Конвейеры), выберите соответствующий конвейер и нажмите кнопку Edit (Изменить).
- Найдите Variables (Переменные) для этого конвейера.
- Добавьте или обновите переменную.
- Выберите параметр сохранить этот секрет значения, чтобы сохранить переменную зашифрованным образом.
- Сохраните конвейер.
Секретные переменные шифруются неактивных с помощью 2048-разрядного ключа RSA. Секреты доступны агенту для задач и сценариев, которые будут использоваться. Будьте осторожны с тем, кто имеет доступ к изменению конвейера.
Внимание
Мы делаем попытку маскировать секреты от отображения в выходных данных Azure Pipelines, но вам по-прежнему необходимо принять меры предосторожности. Никогда не повторять секреты в качестве выходных данных. Некоторые аргументы командной строки журнала операционных систем. Никогда не передавать секреты в командной строке. Вместо этого мы рекомендуем сопоставить секреты с переменными среды.
Мы никогда не маскируем подстроки секретов. Если, например, "abc123" задается как секрет, "abc" не маскируется из журналов. Это позволяет избежать маскирования секретов на слишком детальном уровне, что делает журналы нечитаемыми. По этой причине секреты не должны содержать структурированные данные. Если, например, "{ "foo": "bar" }" имеет значение секрета, "панель" не маскируется из журналов.
В отличие от обычной переменной, они не расшифровываются автоматически в переменные среды для скриптов. Необходимо явно сопоставить секретные переменные.
В следующем примере показано, как сопоставить и использовать секретную переменную, вызванную mySecret в сценариях PowerShell и Bash. Определены две глобальные переменные. GLOBAL_MYSECRETприсваивается значение секретной переменной и GLOBAL_MY_MAPPED_ENV_VAR присваивается значение несекретной переменной.mySecretnonSecretVariable В отличие от обычной переменной конвейера, не вызывается MYSECRETпеременная среды.
Задача PowerShell запускает скрипт для печати переменных.
$(mySecret): это прямая ссылка на секретную переменную и работает.$env:MYSECRET: эта попытка получить доступ к секретной переменной в качестве переменной среды, которая не работает, так как секретные переменные не сопоставляются автоматически с переменными среды.$env:GLOBAL_MYSECRET: эта попытка получить доступ к секретной переменной через глобальную переменную, которая также не работает, так как секретные переменные невозможно сопоставить таким образом.$env:GLOBAL_MY_MAPPED_ENV_VAR: эта переменная обращается к несекретной переменной через глобальную переменную, которая работает.$env:MY_MAPPED_ENV_VAR: этот метод обращается к секретной переменной через переменную среды для конкретной задачи, которая является рекомендуемой способом сопоставления секретных переменных с переменными среды.
variables:
GLOBAL_MYSECRET: $(mySecret) # this will not work because the secret variable needs to be mapped as env
GLOBAL_MY_MAPPED_ENV_VAR: $(nonSecretVariable) # this works because it's not a secret.
steps:
- powershell: |
Write-Host "Using an input-macro works: $(mySecret)"
Write-Host "Using the env var directly does not work: $env:MYSECRET"
Write-Host "Using a global secret var mapped in the pipeline does not work either: $env:GLOBAL_MYSECRET"
Write-Host "Using a global non-secret var mapped in the pipeline works: $env:GLOBAL_MY_MAPPED_ENV_VAR"
Write-Host "Using the mapped env var for this task works and is recommended: $env:MY_MAPPED_ENV_VAR"
env:
MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable
- bash: |
echo "Using an input-macro works: $(mySecret)"
echo "Using the env var directly does not work: $MYSECRET"
echo "Using a global secret var mapped in the pipeline does not work either: $GLOBAL_MYSECRET"
echo "Using a global non-secret var mapped in the pipeline works: $GLOBAL_MY_MAPPED_ENV_VAR"
echo "Using the mapped env var for this task works and is recommended: $MY_MAPPED_ENV_VAR"
env:
MY_MAPPED_ENV_VAR: $(mySecret) # the recommended way to map to an env variable
Выходные данные обоих задач в предыдущем скрипте будут выглядеть следующим образом:
Using an input-macro works: ***
Using the env var directly does not work:
Using a global secret var mapped in the pipeline does not work either:
Using a global non-secret var mapped in the pipeline works: foo
Using the mapped env var for this task works and is recommended: ***
Кроме того, можно использовать секретные переменные вне скриптов. Например, можно сопоставить секретные переменные с задачами с помощью variables определения. В этом примере показано, как использовать секретные переменные $(vmsUser) и $(vmsAdminPass) задачу копирования файлов Azure.
variables:
VMS_USER: $(vmsUser)
VMS_PASS: $(vmsAdminPass)
pool:
vmImage: 'ubuntu-latest'
steps:
- task: AzureFileCopy@4
inputs:
SourcePath: 'my/path'
azureSubscription: 'my-subscription'
Destination: 'AzureVMs'
storage: 'my-storage'
resourceGroup: 'my-rg'
vmsAdminUserName: $(VMS_USER)
vmsAdminPassword: $(VMS_PASS)
Ссылка на секретные переменные в группах переменных
В этом примере показано, как ссылаться на группу переменных в файле YAML, а также как добавлять переменные в YAML. Из группы переменных используются две переменные: user и token. Переменная token является секретом и сопоставляется с переменной $env:MY_MAPPED_TOKEN среды, чтобы ее можно было ссылать в YAML.
Этот YAML вызывает REST для получения списка выпусков и выводит результат.
variables:
- group: 'my-var-group' # variable group
- name: 'devopsAccount' # new variable defined in YAML
value: 'contoso'
- name: 'projectName' # new variable defined in YAML
value: 'contosoads'
steps:
- task: PowerShell@2
inputs:
targetType: 'inline'
script: |
# Encode the Personal Access Token (PAT)
# $env:USER is a normal variable in the variable group
# $env:MY_MAPPED_TOKEN is a mapped secret variable
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $env:USER,$env:MY_MAPPED_TOKEN)))
# Get a list of releases
$uri = "https://vsrm.dev.azure.com/$(devopsAccount)/$(projectName)/_apis/release/releases?api-version=5.1"
# Invoke the REST call
$result = Invoke-RestMethod -Uri $uri -Method Get -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}
# Output releases in JSON
Write-Host $result.value
env:
MY_MAPPED_TOKEN: $(token) # Maps the secret variable $(token) from my-var-group
Внимание
По умолчанию с репозиториями GitHub секретные переменные, связанные с конвейером, недоступны для создания сборок запросов на вытягивание вилок. Дополнительные сведения см. в разделе "Вклады из вилок".
Совместное использование переменных между конвейерами
Чтобы совместно использовать переменные в нескольких конвейерах проекта, используйте веб-интерфейс. В разделе "Библиотека" используйте группы переменных.
Использование выходных переменных из задач
Некоторые задачи определяют выходные переменные, которые можно использовать в подчиненных шагах, заданиях и этапах. В YAML можно получить доступ к переменным между заданиями и этапами с помощью зависимостей.
При ссылке на матричные задания в подчиненных задачах необходимо использовать другой синтаксис. См. раздел "Задание выходной переменной с несколькими заданиями".
Некоторые задачи определяют выходные переменные, которые можно использовать в подчиненных шагах и заданиях на одном этапе. В YAML можно получить доступ к переменным между заданиями с помощью зависимостей.
- Чтобы ссылаться на переменную из другой задачи в одном задании, используйте
TASK.VARIABLE. - Чтобы ссылаться на переменную из задачи из другого задания, используйте
dependencies.JOB.outputs['TASK.VARIABLE'].
Примечание.
По умолчанию каждый этап в конвейере зависит от одного непосредственно перед ним в YAML-файле. Если вам нужно ссылаться на этап, который не находится непосредственно перед текущим, можно переопределить этот автоматический параметр по умолчанию, добавив dependsOn раздел на этап.
Примечание.
В следующих примерах используется стандартный синтаксис конвейера. Если вы используете конвейеры развертывания, оба синтаксиса переменных и условной переменной будут отличаться. Сведения об используемом синтаксисе см. в разделе "Задания развертывания".
В этих примерах предполагается, что у нас есть задача MyTask, которая задает выходную переменную MyVar.
Дополнительные сведения о синтаксисе в выражениях — зависимости.
Использование выходных данных в одном задании
steps:
- task: MyTask@1 # this step generates the output variable
name: ProduceVar # because we're going to depend on it, we need to name the step
- script: echo $(ProduceVar.MyVar) # this step uses the output variable
Использование выходных данных в другом задании
jobs:
- job: A
steps:
# assume that MyTask generates an output variable called "MyVar"
# (you would learn that from the task's documentation)
- task: MyTask@1
name: ProduceVar # because we're going to depend on it, we need to name the step
- job: B
dependsOn: A
variables:
# map the output variable from A into this job
varFromA: $[ dependencies.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
Использование выходных данных на другом этапе
Для использования выходных данных из другого этапа используется stageDependencies.STAGE.JOB.outputs['TASK.VARIABLE']формат для ссылок переменных. На уровне этапа, но не на уровне задания, эти переменные можно использовать в условиях.
Выходные переменные доступны только на следующем нижнем этапе. Если несколько этапов используют одну выходную переменную, используйте dependsOn условие.
stages:
- stage: One
jobs:
- job: A
steps:
- task: MyTask@1 # this step generates the output variable
name: ProduceVar # because we're going to depend on it, we need to name the step
- stage: Two
dependsOn:
- One
jobs:
- job: B
variables:
# map the output variable from A into this job
varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
- stage: Three
dependsOn:
- One
- Two
jobs:
- job: C
variables:
# map the output variable from A into this job
varFromA: $[ stageDependencies.One.A.outputs['ProduceVar.MyVar'] ]
steps:
- script: echo $(varFromA) # this step uses the mapped-in variable
Можно также передавать переменные между этапами с помощью входных данных файла. Для этого необходимо определить переменные на втором этапе на уровне задания, а затем передать переменные в качестве env: входных данных.
## script-a.sh
echo "##vso[task.setvariable variable=sauce;isOutput=true]crushed tomatoes"
## script-b.sh
echo 'Hello file version'
echo $skipMe
echo $StageSauce
## azure-pipelines.yml
stages:
- stage: one
jobs:
- job: A
steps:
- task: Bash@3
inputs:
filePath: 'script-a.sh'
name: setvar
- bash: |
echo "##vso[task.setvariable variable=skipsubsequent;isOutput=true]true"
name: skipstep
- stage: two
jobs:
- job: B
variables:
- name: StageSauce
value: $[ stageDependencies.one.A.outputs['setvar.sauce'] ]
- name: skipMe
value: $[ stageDependencies.one.A.outputs['skipstep.skipsubsequent'] ]
steps:
- task: Bash@3
inputs:
filePath: 'script-b.sh'
name: fileversion
env:
StageSauce: $(StageSauce) # predefined in variables section
skipMe: $(skipMe) # predefined in variables section
- task: Bash@3
inputs:
targetType: 'inline'
script: |
echo 'Hello inline version'
echo $(skipMe)
echo $(StageSauce)
Выходные данные из этапов предыдущего конвейера выглядят следующим образом:
Hello inline version
true
crushed tomatoes
Перечисление переменных
Вы можете перечислить все переменные в конвейере с помощью команды az pipelines variable list . Сведения о начале работы см. в статье "Начало работы с Azure DevOps CLI".
az pipelines variable list [--org]
[--pipeline-id]
[--pipeline-name]
[--project]
Параметры
- org: URL-адрес организации Azure DevOps. Вы можете настроить организацию по умолчанию с помощью
az devops configure -d organization=ORG_URL. Требуется, если не настроено как по умолчанию или выбрано с помощьюgit config. Пример:--org https://dev.azure.com/MyOrganizationName/. - идентификатор конвейера: обязательный, если имя конвейера не задано. Идентификатор конвейера.
- имя конвейера: обязательный, если идентификатор конвейера не указан, но игнорируется, если задан идентификатор конвейера. Имя конвейера.
- проект: имя или идентификатор проекта. Вы можете настроить проект по умолчанию с помощью
az devops configure -d project=NAME_OR_ID. Требуется, если не настроено как по умолчанию или выбрано с помощьюgit config.
Пример
Следующая команда содержит список всех переменных в конвейере с идентификатором 12 и отображает результат в формате таблицы.
az pipelines variable list --pipeline-id 12 --output table
Name Allow Override Is Secret Value
------------- ---------------- ----------- ------------
MyVariable False False platform
NextVariable False True platform
Configuration False False config.debug
Установка переменных в скриптах
Скрипты могут определять переменные, которые позже используются в последующих шагах в конвейере. Все переменные, заданные этим методом, обрабатываются как строки. Чтобы задать переменную из скрипта, используйте синтаксис команды и распечатайте его в stdout.
Задание переменной область задания из скрипта
Чтобы задать переменную из скрипта, используйте task.setvariableкоманду ведения журнала. Это обновляет переменные среды для последующих заданий. Последующие задания имеют доступ к новой переменной с синтаксисом макросов и в задачах в качестве переменных среды.
Если issecret значение равно true, значение переменной будет сохранено в виде секрета и маскировано из журнала. Дополнительные сведения о секретных переменных см . в командах ведения журнала.
steps:
# Create a variable
- bash: |
echo "##vso[task.setvariable variable=sauce]crushed tomatoes" # remember to use double quotes
# Use the variable
# "$(sauce)" is replaced by the contents of the `sauce` variable by Azure Pipelines
# before handing the body of the script to the shell.
- bash: |
echo my pipeline variable is $(sauce)
Последующие шаги также будут добавлены в среду переменной конвейера. Нельзя использовать переменную на шаге, который он определен.
steps:
# Create a variable
# Note that this does not update the environment of the current script.
- bash: |
echo "##vso[task.setvariable variable=sauce]crushed tomatoes"
# An environment variable called `SAUCE` has been added to all downstream steps
- bash: |
echo "my environment variable is $SAUCE"
- pwsh: |
Write-Host "my environment variable is $env:SAUCE"
Выходные данные предыдущего конвейера.
my environment variable is crushed tomatoes
my environment variable is crushed tomatoes
Задание выходной переменной с несколькими заданиями
Если вы хотите сделать переменную доступной для будущих заданий, ее необходимо пометить как выходную переменную с помощью isOutput=true. Затем его можно сопоставить с будущими заданиями с помощью синтаксиса $[] и включая имя шага, которое задает переменную. Выходные переменные с несколькими заданиями работают только на одном этапе.
Чтобы передать переменные заданиям на разных этапах, используйте синтаксис зависимостей этапа.
Примечание.
По умолчанию каждый этап в конвейере зависит от одного непосредственно перед ним в YAML-файле. Поэтому каждый этап может использовать выходные переменные из предыдущего этапа. Чтобы получить доступ к дальнейшим этапам, необходимо изменить граф зависимостей, например, если для этапа 3 требуется переменная с этапа 1, необходимо объявить явную зависимость от этапа 1.
При создании выходной переменной с несколькими заданиями следует назначить выражение переменной. В этом YAML $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] присваивается переменной $(myVarFromJobA).
jobs:
# Set an output variable from job A
- job: A
pool:
vmImage: 'windows-latest'
steps:
- powershell: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable into job B
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobA: $[ dependencies.A.outputs['setvarStep.myOutputVar'] ] # map in the variable
# remember, expressions require single quotes
steps:
- script: echo $(myVarFromJobA)
name: echovar
Выходные данные предыдущего конвейера.
this is the value
this is the value
Если вы задаете переменную из одной стадии в другую, используйте stageDependencies.
stages:
- stage: A
jobs:
- job: A1
steps:
- bash: echo "##vso[task.setvariable variable=myStageOutputVar;isOutput=true]this is a stage output var"
name: printvar
- stage: B
dependsOn: A
variables:
myVarfromStageA: $[ stageDependencies.A.A1.outputs['printvar.myStageOutputVar'] ]
jobs:
- job: B1
steps:
- script: echo $(myVarfromStageA)
Если вы задаете переменную из матрицы или среза, то для ссылки на переменную при доступе к ней из подчиненного задания необходимо включить следующее:
- Имя задания.
- Шаг.
jobs:
# Set an output variable from a job with a matrix
- job: A
pool:
vmImage: 'ubuntu-latest'
strategy:
maxParallel: 2
matrix:
debugJob:
configuration: debug
platform: x64
releaseJob:
configuration: release
platform: x64
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the $(configuration) value"
name: setvarStep
- bash: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the debug job
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobADebug: $[ dependencies.A.outputs['debugJob.setvarStep.myOutputVar'] ]
steps:
- script: echo $(myVarFromJobADebug)
name: echovar
jobs:
# Set an output variable from a job with slicing
- job: A
pool:
vmImage: 'ubuntu-latest'
parallel: 2 # Two slices
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the slice $(system.jobPositionInPhase) value"
name: setvarStep
- script: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the job for the first slice
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ]
steps:
- script: "echo $(myVarFromJobsA1)"
name: echovar
Обязательно префиксировать имя задания в выходные переменные задания развертывания . В этом случае имя задания :A
jobs:
# Set an output variable from a deployment
- deployment: A
pool:
vmImage: 'ubuntu-latest'
environment: staging
strategy:
runOnce:
deploy:
steps:
- bash: echo "##vso[task.setvariable variable=myOutputVar;isOutput=true]this is the deployment variable value"
name: setvarStep
- bash: echo $(setvarStep.myOutputVar)
name: echovar
# Map the variable from the job for the first slice
- job: B
dependsOn: A
pool:
vmImage: 'ubuntu-latest'
variables:
myVarFromDeploymentJob: $[ dependencies.A.outputs['A.setvarStep.myOutputVar'] ]
steps:
- bash: "echo $(myVarFromDeploymentJob)"
name: echovar
Задание переменных с помощью выражений
Переменную можно задать с помощью выражения. Мы уже столкнулись с одним из этих случаев, чтобы задать переменную выходным данным другого из предыдущего задания.
- job: B
dependsOn: A
variables:
myVarFromJobsA1: $[ dependencies.A.outputs['job1.setvarStep.myOutputVar'] ] # remember to use single quotes
Для задания переменной можно использовать любое из поддерживаемых выражений. Ниже приведен пример задания переменной для действия в качестве счетчика, который начинается с 100, увеличивается на 1 для каждого запуска и получает сброс до 100 каждый день.
jobs:
- job:
variables:
a: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 100)]
steps:
- bash: echo $(a)
Дополнительные сведения о счетчиках, зависимостях и других выражениях см . в разделе "Выражения".
Настройка наборных переменных для шагов
Можно определить на шаге или указать settableVariables , что переменные не могут быть заданы.
В этом примере скрипт не может задать переменную.
steps:
- script: echo This is a step
target:
settableVariables: none
В этом примере скрипт разрешает переменную sauce , но не переменную secretSauce. На странице запуска конвейера появится предупреждение.
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 имеет приоритет.
Расширение переменных
Когда вы устанавливаете переменную с одним и тем же именем в нескольких областях, применяется следующий приоритет (сначала самый высокий приоритет).
- Переменная уровня задания, заданная в файле YAML.
- Переменная уровня этапа, заданная в файле YAML.
- Переменная уровня конвейера, заданная в файле YAML.
- Переменная, заданная во время очереди.
- Переменная конвейера, заданная в пользовательском интерфейсе параметров конвейера.
В следующем примере та же переменная 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"
Связанные статьи
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по