In response to my post on GitHub and Azure Pipelines, I got the following question on Reddit.
Does this automatically detect branches? From your screenshot, you’re building master. If you copy to feature-A, does a new pipeline automatically get created and built?
When I initially answered this question I didn’t go deep enough. The answer to does a new pipeline automatically get created and built is no as I replied, but I think the intent of the question is do I have to go set up a new pipeline every time I create a new branch and the answer to that is also no. The existing pipeline will be triggered when any change is checked in on any branch by default. Do note that it won’t be triggered when the branch is created only when a change is checked in.
Limiting Builds
There are a couple of ways to control what branches trigger continuous integration builds. The first is by making edits to the azure-pipeline.yml file in the repo and the second is via an override in the Azure Pipeline.
YAML
The official Build pipeline triggers docs are really good, but I will cover the basic here for including branches and excluding branches. Check for docs for information on path includes/excludes as well as how to control PR validation. As an example here is the yaml file used to define a build in this repo.
pool: vmImage: 'Ubuntu 16.04' variables: buildConfiguration: 'Release' steps: - script: dotnet build Sqlite --configuration $(buildConfiguration) displayName: 'dotnet build $(buildConfiguration)'
In order to control what branches get built, we need to add a trigger section. The smilest example is to list the branches you want to build. Ending wildcards are allowed. See the following example (trigger section taken from the official docs).
pool: vmImage: 'Ubuntu 16.04' variables: buildConfiguration: 'Release' steps: - script: dotnet build Sqlite --configuration $(buildConfiguration) displayName: 'dotnet build $(buildConfiguration)' trigger: - master - releases/*
This would build master and all branches under releases, but nothing else. The following shows how to use includes and excludes together. Again the triggers section is taken from the official docs.
pool:
vmImage: 'Ubuntu 16.04'
variables:
buildConfiguration: 'Release'
steps:
- script: dotnet build Sqlite --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
trigger:
branches:
include:
- master
- releases/*
exclude:
- releases/old*
This would build master and everything in under releases that does not start with old. Really go read the official docs on this one to see all the ins and outs.
Azure Pipelines
To override the CI build from Azure DevOp go to the build in question and click Edit.
Next, select Triggers and Continuous integration and check Override YAML.
After checking the override you will see a lot more options light up. As you can see in the following screenshot the same include and exclude options are available with the same options for wildcards.
Wrapping Up
As you can see Azure Pipelines provides a lot of flex ability in how a build gets triggered. On top of what I covered here, there are also options for setting up scheduled builds as well as trigging a build with another build is completed. If you hit a scenario that couldn’t be covered I would love to hear about it in the comments.
Also published on Medium.