- Article
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Templates let you define reusable content, logic, and parameters in YAML pipelines. To work with templates effectively, you'll need to have a basic understanding of Azure Pipelines key concepts such as stages, steps, and jobs.
Templates can help you speed up development. For example, you can have a series of the same tasks in a template and then include the template multiple times in different stages of your YAML pipeline.
Templates can also help you secure your pipeline. When a template controls what is allowed in a pipeline, the template defines logic that another file must follow. For example, you may want to restrict what tasks are allowed to run. For that scenario, you can use template to prevent someone from successfully running a task that violates your organization's security policies.
There are two types of templates: includes and extends.
- Includes templates let you insert reusable content with a template. If a template is used to include content, it functions like an include directive in many programming languages. Content from one file is inserted into another file.
- Extends template control what is allowed in a pipeline. When an extends template controls what is allowed in a pipeline, the template defines logic that another file must follow.
To take full advantage of templates, you should also use template expressions and template parameters.
Imposed limits
Templates and template expressions can cause explosive growth to the size and complexity of a pipeline.To help prevent runaway growth, Azure Pipelines imposes the following limits:
- No more than 100 separate YAML files may be included (directly or indirectly)
- No more than 20 levels of template nesting (templates including other templates)
- No more than 10 megabytes of memory consumed while parsing the YAML (in practice, this is typically between 600 KB - 2 MB of on-disk YAML, depending on the specific features used)
Use templates to define your logic once and then reuse it several times. Templates combine the content of multiple YAML files into a single pipeline. You can pass parameters into a template from your parent pipeline.
Extend from a template
To increase security, you can enforce that a pipeline extends from a particular template. The file start.yml
defines the parameter buildSteps
, which is then used in the pipeline azure-pipelines.yml
.In start.yml
, if a buildStep
gets passed with a script step, then it is rejected and the pipeline build fails.When extending from a template, you can increase security by adding a required template approval.
# File: start.ymlparameters:- name: buildSteps # the name of the parameter is buildSteps type: stepList # data type is StepList default: [] # default value of buildStepsstages:- 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.ymltrigger:- mainextends: 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"
Extend from a template with resources
You can also use extends
to extend from a template in your Azure pipeline that contains resources.
# File: azure-pipelines.ymltrigger:- noneextends: template: resource-template.yml
# File: resource-template.ymlresources: pipelines: - pipeline: my-pipeline source: sourcePipelinesteps:- script: echo "Testing resource template"
Insert a template
You can copy content from one YAML and reuse it in a different YAML. Copying content from one YAML to another saves you from having to manually include the same logic in multiple places. The include-npm-steps.yml
file template contains steps that are reused in azure-pipelines.yml
.
Note
Template files need to exist on your filesystem at the start of a pipeline run. You can't reference templates in an artifact.
# File: templates/include-npm-steps.ymlsteps:- script: npm install- script: yarn install- script: npm run compile
# File: azure-pipelines.ymljobs:- 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
Step reuse
You can insert a template to reuse one or more steps across several jobs.In addition to the steps from the template, each job can define more steps.
# File: templates/npm-steps.ymlsteps:- script: npm install- script: npm test
# File: azure-pipelines.ymljobs:- 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.
Job reuse
Much like steps, jobs can be reused with templates.
# File: templates/jobs.ymljobs:- 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.ymljobs:- template: templates/jobs.yml # Template reference
When working with multiple jobs, remember to remove the name of the job in the template file, so as to avoid conflict
# File: templates/jobs.ymljobs:- job: pool: vmImage: 'ubuntu-latest' steps: - bash: echo "Hello Ubuntu"- job: pool: vmImage: 'windows-latest' steps: - bash: echo "Hello Windows"
# File: azure-pipelines.ymljobs:- template: templates/jobs.yml # Template reference- template: templates/jobs.yml # Template reference- template: templates/jobs.yml # Template reference
Stage reuse
Stages can also be reused with templates.
# File: templates/stages1.ymlstages:- stage: Angular jobs: - job: angularinstall steps: - script: npm install angular
# File: templates/stages2.ymlstages:- stage: Build jobs: - job: build steps: - script: npm run build
# File: azure-pipelines.ymltrigger:- mainpool: 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
Job, stage, and step templates with parameters
# File: templates/npm-with-params.ymlparameters:- 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
When you consume the template in your pipeline, specify values forthe template parameters.
# File: azure-pipelines.ymljobs:- 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'
You can also use parameters with step or stage templates.For example, steps with parameters:
# File: templates/steps-with-params.ymlparameters:- name: 'runExtendedTests' # defaults for any parameters that aren't specified type: boolean default: falsesteps:- script: npm test- ${{ if eq(parameters.runExtendedTests, true) }}: - script: npm test --extended
When you consume the template in your pipeline, specify values forthe template parameters.
# File: azure-pipelines.ymlsteps:- script: npm install- template: templates/steps-with-params.yml # Template reference parameters: runExtendedTests: 'true'
Note
Scalar parameters without a specified type are treated as strings.For example, eq(true, parameters['myparam'])
will return true
, even if the myparam
parameter is the word false
, if myparam
is not explicitly made boolean
.Non-empty strings are cast to true
in a Boolean context.That expression could be rewritten to explicitly compare strings: eq(parameters['myparam'], 'true')
.
Parameters aren't limited to scalar strings.See the list of data types.For example, using the object
type:
# azure-pipelines.ymljobs:- template: process.yml parameters: pool: # this parameter is called `pool` vmImage: ubuntu-latest # and it's a mapping rather than a string# process.ymlparameters:- name: 'pool' type: object default: {}jobs:- job: build pool: ${{ parameters.pool }}
Variable reuse
Variables can be defined in one YAML and included in another template. This could be useful if you want to store all of your variables in one file. If you're using a template to include variables in a pipeline, the included template can only be used to define variables. You can use steps and more complex logic when you're extending from a template.Use parameters instead of variables when you want to restrict type.
In this example, the variable favoriteVeggie
is included in azure-pipelines.yml
.
# File: vars.ymlvariables: favoriteVeggie: 'brussels sprouts'
# File: azure-pipelines.ymlvariables:- template: vars.yml # Template referencesteps:- script: echo My favorite vegetable is ${{ variables.favoriteVeggie }}.
Variable templates with parameter
You can pass parameters to variables with templates. In this example, you're passing the DIRECTORY
parameter to a RELEASE_COMMAND
variable.
# File: templates/package-release-with-params.ymlparameters:- 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}'
When you consume the template in your pipeline, specify values forthe template parameters.
# File: azure-pipelines.ymlvariables: # 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
Reference template paths
Template paths can be an absolute path within the repository or relative to the file that does the including.
To use an absolute path, the template path must start with a /
. All other paths are considered relative.
Here's an example nested hierarchy.
|+-- fileA.yml|+-- dir1/ | +-- fileB.yml | +-- dir2/ | +-- fileC.yml
Then, in fileA.yml
you can reference fileB.yml
and fileC.yml
like this.
steps:- template: dir1/fileB.yml- template: dir1/dir2/fileC.yml
If fileC.yml
is your starting point, you can include fileA.yml
and fileB.yml
like this.
steps:- template: ../../fileA.yml- template: ../fileB.yml
When fileB.yml
is your starting point, you can include fileA.yml
and fileC.yml
like this.
steps:- template: ../fileA.yml- template: dir2/fileC.yml
Alternatively, fileB.yml
could refer to fileA.yml
and fileC.yml
using absolute paths like this.
steps:- template: /fileA.yml- template: /dir1/dir2/fileC.yml
Use other repositories
You can keep your templates in other repositories.For example, suppose you have a core pipeline that you want all of your app pipelines to use.You can put the template in a core repo and then refer to it from each of your app repos:
# Repo: Contoso/BuildTemplates# File: common.ymlparameters:- name: 'vmImage' default: 'ubuntu-22.04' type: stringjobs:- job: Build pool: vmImage: ${{ parameters.vmImage }} steps: - script: npm install - script: npm test
Now you can reuse this template in multiple pipelines.Use the resources
specification to provide the location of the core repo.When you refer to the core repo, use @
and the name you gave it in resources
.
# Repo: Contoso/LinuxProduct# File: azure-pipelines.ymlresources: repositories: - repository: templates type: github name: Contoso/BuildTemplatesjobs:- template: common.yml@templates # Template reference
# Repo: Contoso/WindowsProduct# File: azure-pipelines.ymlresources: repositories: - repository: templates type: github name: Contoso/BuildTemplates ref: refs/tags/v1.0 # optional ref to pin tojobs:- template: common.yml@templates # Template reference parameters: vmImage: 'windows-latest'
For type: github
, name
is <identity>/<repo>
as in the examples above.For type: git
(Azure Repos), name
is <project>/<repo>
.If that project is in a separate Azure DevOps organization, you'll need to configure a service connection of type Azure Repos/Team Foundation Server
with access to the project and include that in YAML:
resources: repositories: - repository: templates name: Contoso/BuildTemplates endpoint: myServiceConnection # Azure DevOps service connectionjobs:- template: common.yml@templates
Repositories are resolved only once, when the pipeline starts up.After that, the same resource is used for the duration of the pipeline.Only the template files are used.Once the templates are fully expanded, the final pipeline runs as if it were defined entirely in the source repo.This means that you can't use scripts from the template repo in your pipeline.
If you want to use a particular, fixed version of the template, be sure to pin to a ref
.The refs
are either branches (refs/heads/<name>
) or tags (refs/tags/<name>
).If you want to pin a specific commit, first create a tag pointing to that commit, then pin to that tag.
Note
If no ref
is specified, the pipeline will default to using refs/heads/main
.
You can also pin to a specific commit in Git with the SHA value for a repository resource. The SHA value is a 40-character checksum hash that uniquely identifies the commit.
resources: repositories: - repository: templates type: git name: Contoso/BuildTemplates ref: 1234567890abcdef1234567890abcdef12345678
You may also use @self
to refer to the repository where the original pipeline was found.This is convenient for use in extends
templates if you want to refer back to contents in the extending pipeline's repository.For example:
# Repo: Contoso/Central# File: template.ymljobs:- 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.ymlresources: repositories: - repository: templates type: git name: Contoso/Centralextends: template: template.yml@templates
# Repo: Contoso/MyProduct# File: BuildJobs.ymljobs:- job: Build steps: []
FAQ
How can I use variables inside of templates?
There are times when it may be useful to set parameters to values based on variables. Parameters are expanded early in processing a pipeline run so not all variables are available. To see what predefined variables are available in templates, see Use predefined variables.
In this example, the predefined variables Build.SourceBranch
and Build.Reason
are used in conditions in template.yml.
# File: azure-pipelines.ymltrigger:- mainextends: template: template.yml
# File: template.ymlsteps:- 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