What is the purpose of `Build branch filters` in Continuous deployment trigger?

0
votes

A build pipeline can be tied to only 1 source branch.

In release pipeline, we configure an artifact by selecting the source build pipeline. So a release artifact can be tied to only 1 build pipeline.

What is the purpose of Build branch filters in Continuous deployment trigger?

1
azureazure-devopsazure-pipelinesazure-pipelines-release-pipeline
Your opening premise is flawed. A build pipeline can be tied to only 1 source branch is an incorrect statement unless you're talking about TFVC. Are you using TFVC? – Daniel Mann
On my build pipeline, under GET SOURCES, I have selected azure repos git and selected the repo name and branch name. Does that answer your question? – variable
That's the default branch. Depending on what you define as triggers, the build will run on the triggering branch. When queuing a build, you can choose any branch you want. – Daniel Mann
Ok thanks I was under a wrong impression that - irrespective of which branch is selected in trigger, always the code from default branch is used by build pipeline. Thank you for clarifying. – variable
@DanielMann - I have enabled 'continuous deployment trigger' (not added any branch filter) and disabled 'Pull request trigger'. Now when I raise PR, then the PR triggers a build (since I have build validation configured). Once build completes, it triggers a release. Why does this happen when I have the "pull request trigger" disabled? The triggering of release prior to PR approval is prevented only when I add a branch filter to the "continuous deployment trigger". – variable

1 Answers

2
votes

Let say that your code base was updated. You want deploy only if build was made over specific branch (example develop).

In that scenario Build Branch Filter looks fairly redundant... but what if:

  1. You want to trigger new deployment for every latest artifact, built from each feature branch to get them tested. You have to filter for feature/*.

  2. You want to trigger new deployments if your release branches are updated, but some of them are deprecated and you need to filter them out. I that scenario specify one include filter release/* and second exclude filter release/old*.

Anyway.. in most of the cases the filter and the branch name (in artifact) will match each other. Still sometimes it can be heady to trigger deployment from multiple branches or filter something out.

In regards to your comment, I uploaded part of the yaml build. In fact one build can create artifacts from all branches in repository if you want.

trigger:
  branches:
    include:
    - feature/*
    - bugfix/*
    - release/*
    - develop
    - master
    exclude:
    - experimental/*