Pipeline Triggers
There are a lot of topics to cover for YAML-based Pipelines in Azure DevOps. So, I will be breaking this up into a multi-part series. This section will be updated over time with links to the whole series of articles once they are written.
Part 1 - The Basics
Part 2 - Structure of a YAML Pipeline
Part 3 - Pipeline Triggers (you're reading it now!)
Part 4 - Pipeline Resources
Part 5 - Pools and Agents
Part 6 - Parameters and Variables
Part 7 - Stages, Jobs, and Steps
There are 3 different kinds of Triggers that can be defined at the Pipeline-level. They are CI Triggers, PR Triggers, and Scheduled Triggers. We will go over all 3 of these Triggers in this post.
There are an additional 6 Triggers that can be defined in the 'Resources' section of a Pipeline. These Resource Triggers will be covered in the next post.
CI Triggers
Your Pipeline's YAML file is stored in a repository. CI Triggers will automatically kick off a run of your Pipeline when updates are made to this repository. CI Triggers are defined by the trigger: parameter.
It is important to note that CI Triggers are optional. If you omit the trigger: parameter, then ANY update to ANY branch of your repository will cause your Pipeline to trigger. Depending on your scenario this may be undesirable behavior.
There are three possible options for defining CI Triggers:
Setting the batch: parameter to true means only one instance of the pipeline will run at a time. While the second run of the pipeline is waiting for its turn, it will batch up all of the changes that have been made while waiting. When its finally able to run it will apply all of those changes at once.
You need to specify either branches: or tags: or you could even specify both. If you specify both, then both of them will be considered, and if at least one of them matches, then the pipeline will be triggered.
The paths: parameter cannot be used by itself, it can only be used in combination with the branches: parameter. Paths in Git are case-sensitive.
PR Triggers
Your Pipeline's YAML file is stored in a repository. PR Triggers will automatically kick off a run of your Pipeline when Pull Requests are made to this repository. PR Triggers are defined by the pr: parameter.
PR Triggers in YAML Pipelines are only supported with GitHub or BitBucket Cloud repos.
It is important to note that PR Triggers are optional. If you omit the pr: parameter, then ANY Pull Request to ANY branch of your repository will cause your Pipeline to trigger. Depending on your scenario this may be undesirable behavior.
There are three possible options for defining PR Triggers:
The paths: parameter cannot be used by itself, it can only be used in combination with the branches: parameter. Paths in Git are case-sensitive.
Scheduled Triggers
Scheduled Triggers will automatically start a run of your Pipeline based on one or more schedules that you define. Scheduled Triggers are defined by the schedules: parameter.
Scheduled Triggers are optional. If you omit the schedules: parameter, then no scheduled runs of your Pipeline will occur.
Schedules can be defined in 2 different places (see below): in your YAML Pipeline, or in the Azure DevOps UI. If you define schedules in both places, then the ones in the Azure DevOps UI will be the only ones that run.
Defining Scheduled Triggers:
There are a couple additional notes that I would like to point out regarding these 3 types of Triggers.
You can not use Pipeline Variables inside your Trigger definitions. This is because Pipeline Variables are evaluated AFTER Pipeline Triggers are evaluated.
Triggers are not supported inside Template files. (templates will be covered in a later post)
To summarize, we discussed the 3 Trigger options that can be used at the root of your Pipeline:
Trigger on updates to the Pipeline's repo
Trigger on pull requests to the Pipeline's repo
Trigger on a schedule
Next up, we'll discuss Resources in depth, including 6 more Triggers that we can use.