Справочник по использованию шаблонов

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г.

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

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

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

Существует два типа шаблонов: включает и расширяет.

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

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

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

Расширение из шаблона

Чтобы повысить безопасность, можно принудительно применить конвейер к определенному шаблону. Файл start.yml определяет параметр buildSteps, который затем используется в конвейере azure-pipelines.yml. В start.yml, если buildStep передается с помощью шага скрипта, он отклоняется и сборка конвейера завершается сбоем. При расширении из шаблона можно повысить безопасность, добавив необходимое утверждение шаблона.

# File: start.yml
parameters:
- name: buildSteps # the name of the parameter is buildSteps
  type: stepList # data type is StepList
  default: [] # default value of buildSteps
stages:
- stage: secure_buildstage
  pool:
    vmImage: windows-latest
  jobs:
  - job: secure_buildjob
    steps:
    - script: echo This happens before code 
      displayName: 'Base: Pre-build'
    - script: echo Building
      displayName: 'Base: Build'

    - ${{ each step in parameters.buildSteps }}:
      - ${{ each pair in step }}:
          ${{ if ne(pair.value, 'CmdLine@2') }}:
            ${{ pair.key }}: ${{ pair.value }}       
          ${{ if eq(pair.value, 'CmdLine@2') }}: 
            # Step is rejected by raising a YAML syntax error: Unexpected value 'CmdLine@2'
            '${{ pair.value }}': error         

    - script: echo This happens after code
      displayName: 'Base: Signing'
# File: azure-pipelines.yml
trigger:
- main

extends:
  template: start.yml
  parameters:
    buildSteps:  
      - bash: echo Test #Passes
        displayName: succeed
      - bash: echo "Test"
        displayName: succeed
      # Step is rejected by raising a YAML syntax error: Unexpected value 'CmdLine@2'
      - task: CmdLine@2
        inputs:
          script: echo "Script Test"
      # Step is rejected by raising a YAML syntax error: Unexpected value 'CmdLine@2'
      - script: echo "Script Test"

Расширение шаблона с помощью ресурсов

Вы также можете использовать для extends расширения из шаблона в конвейере Azure, который содержит ресурсы.

# File: azure-pipelines.yml
trigger:
- none

extends:
  template: resource-template.yml
# File: resource-template.yml
resources:
  pipelines:
  - pipeline: my-pipeline 
    source: sourcePipeline

steps:
- script: echo "Testing resource template"

Вставка шаблона

Вы можете скопировать содержимое из одного YAML и повторно использовать его в другом YAML. Копирование содержимого из одного YAML в другой избавляет вас от необходимости вручную включать одну и ту же логику в нескольких местах. Шаблон include-npm-steps.yml файла содержит шаги, которые повторно используются в azure-pipelines.yml.

Примечание

Файлы шаблонов должны существовать в файловой системе в начале выполнения конвейера. Вы не можете ссылаться на шаблоны в артефакте.

# File: templates/include-npm-steps.yml

steps:
- script: npm install
- script: yarn install
- script: npm run compile
# File: azure-pipelines.yml

jobs:
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: templates/include-npm-steps.yml  # Template reference
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: templates/include-npm-steps.yml  # Template reference

Повторное использование шага

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

# File: templates/npm-steps.yml
steps:
- script: npm install
- script: npm test
# File: azure-pipelines.yml

jobs:
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: templates/npm-steps.yml  # Template reference

- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - template: templates/npm-steps.yml  # Template reference

- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo This script runs before the template's steps, only on Windows.
  - template: templates/npm-steps.yml  # Template reference
  - script: echo This step runs after the template's steps.

Повторное использование задания

Как и шаги, задания можно повторно использовать с помощью шаблонов.

# File: templates/jobs.yml
jobs:
- job: Ubuntu
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello Ubuntu"

- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - bash: echo "Hello Windows"
# File: azure-pipelines.yml

jobs:
- template: templates/jobs.yml  # Template reference

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

# File: templates/jobs.yml
jobs:
- job: 
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello Ubuntu"

- job:
  pool:
    vmImage: 'windows-latest'
  steps:
  - bash: echo "Hello Windows"
# File: azure-pipelines.yml

jobs:
- template: templates/jobs.yml  # Template reference
- template: templates/jobs.yml  # Template reference
- template: templates/jobs.yml  # Template reference

Повторное использование этапа

Этапы также можно повторно использовать с шаблонами.

# File: templates/stages1.yml
stages:
- stage: Angular
  jobs:
  - job: angularinstall
    steps:
    - script: npm install angular
# File: templates/stages2.yml
stages:
- stage: Build
  jobs:
  - job: build
    steps:
    - script: npm run build
# File: azure-pipelines.yml
trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Install
  jobs: 
  - job: npminstall
    steps:
    - task: Npm@1
      inputs:
        command: 'install'
- template: templates/stages1.yml # Template reference
- template: templates/stages2.yml # Template reference

Шаблоны заданий, этапов и шагов с параметрами

# File: templates/npm-with-params.yml

parameters:
- name: name  # defaults for any parameters that aren't specified
  default: ''
- name: vmImage
  default: ''

jobs:
- job: ${{ parameters.name }}
  pool: 
    vmImage: ${{ parameters.vmImage }}
  steps:
  - script: npm install
  - script: npm test

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

# File: azure-pipelines.yml

jobs:
- template: templates/npm-with-params.yml  # Template reference
  parameters:
    name: Linux
    vmImage: 'ubuntu-latest'

- template: templates/npm-with-params.yml  # Template reference
  parameters:
    name: macOS
    vmImage: 'macOS-latest'

- template: templates/npm-with-params.yml  # Template reference
  parameters:
    name: Windows
    vmImage: 'windows-latest'

Вы также можете использовать параметры с шаблонами шагов или этапов. Например, шаги с параметрами:

# File: templates/steps-with-params.yml

parameters:
- name: 'runExtendedTests'  # defaults for any parameters that aren't specified
  type: boolean
  default: false

steps:
- script: npm test
- ${{ if eq(parameters.runExtendedTests, true) }}:
  - script: npm test --extended

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

# File: azure-pipelines.yml

steps:
- script: npm install

- template: templates/steps-with-params.yml  # Template reference
  parameters:
    runExtendedTests: 'true'

Примечание

Скалярные параметры без указанного типа обрабатываются как строки. Например, eq(true, parameters['myparam']) возвращает true, даже если myparam параметр является словом false, если myparam явно не задан boolean. Непустые строки приведены к true в логическом контексте. Это выражение можно переписать для явного сравнения строк: eq(parameters['myparam'], 'true').

Параметры не ограничиваются скалярными строками. См. список типов данных. Например, при использовании object типа :

# azure-pipelines.yml
jobs:
- template: process.yml
  parameters:
    pool:   # this parameter is called `pool`
      vmImage: ubuntu-latest  # and it's a mapping rather than a string


# process.yml
parameters:
- name: 'pool'
  type: object
  default: {}

jobs:
- job: build
  pool: ${{ parameters.pool }}

Повторное использование переменной

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

В этом примере переменная favoriteVeggie включена в azure-pipelines.yml.

# File: vars.yml
variables:
  favoriteVeggie: 'brussels sprouts'
# File: azure-pipelines.yml

variables:
- template: vars.yml  # Template reference

steps:
- script: echo My favorite vegetable is ${{ variables.favoriteVeggie }}.

Шаблоны переменных с параметром

Параметры можно передавать в переменные с помощью шаблонов. В этом примере вы передаете DIRECTORY параметр в переменную RELEASE_COMMAND .

# File: templates/package-release-with-params.yml

parameters:
- name: DIRECTORY 
  type: string
  default: "." # defaults for any parameters that specified with "." (current directory)

variables:
- name: RELEASE_COMMAND
  value: grep version ${{ parameters.DIRECTORY }}/package.json | awk -F \" '{print $4}'  

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

# File: azure-pipelines.yml

variables: # Global variables
  - template: package-release-with-params.yml # Template reference
    parameters:
      DIRECTORY: "azure/checker"

pool:
  vmImage: 'ubuntu-latest'

stages:
- stage: Release_Stage 
  displayName: Release Version
  variables: # Stage variables
  - template: package-release-with-params.yml  # Template reference
    parameters:
      DIRECTORY: "azure/todo-list"
  jobs: 
  - job: A
    steps: 
    - bash: $(RELEASE_COMMAND) #output release command

Ссылки на пути к шаблонам

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

|
+-- fileA.yml
|
+-- dir1/
     |
     +-- fileB.yml
     |
     +-- dir2/
          |
          +-- fileC.yml

Затем в fileA.yml вы можете ссылаться и fileC.ymlfileB.yml как показано ниже.

steps:
- template: dir1/fileB.yml
- template: dir1/dir2/fileC.yml

Если fileC.yml это ваша отправная точка, вы можете включить fileA.yml и fileB.yml , как показано ниже.

steps:
- template: ../../fileA.yml
- template: ../fileB.yml

Когда fileB.yml это ваша отправная точка, вы можете включить fileA.yml и fileC.yml , как это.

steps:
- template: ../fileA.yml
- template: dir2/fileC.yml

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

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

# Repo: Contoso/BuildTemplates
# File: common.yml
parameters:
- name: 'vmImage'
  default: 'ubuntu-22.04'
  type: string

jobs:
- job: Build
  pool:
    vmImage: ${{ parameters.vmImage }}
  steps:
  - script: npm install
  - script: npm test

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

# Repo: Contoso/LinuxProduct
# File: azure-pipelines.yml
resources:
  repositories:
    - repository: templates
      type: github
      name: Contoso/BuildTemplates

jobs:
- template: common.yml@templates  # Template reference
# Repo: Contoso/WindowsProduct
# File: azure-pipelines.yml
resources:
  repositories:
    - repository: templates
      type: github
      name: Contoso/BuildTemplates
      ref: refs/tags/v1.0 # optional ref to pin to

jobs:
- template: common.yml@templates  # Template reference
  parameters:
    vmImage: 'windows-latest'

Для type: githubимеет значение <identity>/<repo> , name как в приведенных выше примерах. Для type: git (Azure Repos) name имеет значение <project>/<repo>. Если этот проект находится в отдельной организации Azure DevOps, необходимо настроить подключение службы типа Azure Repos/Team Foundation Server с доступом к проекту и включить его в YAML:

resources:
  repositories:
  - repository: templates
    name: Contoso/BuildTemplates
    endpoint: myServiceConnection # Azure DevOps service connection
jobs:
- template: common.yml@templates

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

Если вы хотите использовать определенную фиксированную версию шаблона, обязательно закрепите на ref. Являются refs ветвями (refs/heads/<name>) или тегами (refs/tags/<name>). Если вы хотите закрепить определенную фиксацию, сначала создайте тег, указывающий на эту фиксацию, а затем закрепите его.

Примечание

Если параметр не ref указан, конвейер по умолчанию будет использовать refs/heads/main.

Можно также использовать для @self ссылки на репозиторий, в котором был найден исходный конвейер. Это удобно для использования в extends шаблонах, если вы хотите вернуться к содержимому в репозитории конвейера расширения. Например:

# Repo: Contoso/Central
# File: template.yml
jobs:
- job: PreBuild
  steps: []

  # Template reference to the repo where this template was
  # included from - consumers of the template are expected
  # to provide a "BuildJobs.yml"
- template: BuildJobs.yml@self

- job: PostBuild
  steps: []
# Repo: Contoso/MyProduct
# File: azure-pipelines.yml
resources:
  repositories:
    - repository: templates
      type: git
      name: Contoso/Central

extends:
  template: template.yml@templates
# Repo: Contoso/MyProduct
# File: BuildJobs.yml
jobs:
- job: Build
  steps: []

Вопросы и ответы

Как использовать переменные в шаблонах?

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

В этом примере предопределенные переменные Build.SourceBranch и Build.Reason используются в условиях в template.yml.

# File: azure-pipelines.yml
trigger:
- main

extends:
  template: template.yml
# File: template.yml
steps:
- script: echo Build.SourceBranch = $(Build.SourceBranch) # outputs refs/heads/main
- script: echo Build.Reason = $(Build.Reason) # outputs IndividualCI
- ${{ if eq(variables['Build.SourceBranch'], 'refs/heads/main') }}: 
  - script: echo I run only if Build.SourceBranch = refs/heads/main 
- ${{ if eq(variables['Build.Reason'], 'IndividualCI') }}: 
  - script: echo I run only if Build.Reason = IndividualCI 
- script: echo I run after the conditions