How to automatically trigger a build for a new branch with wildcard included branch and using path filters?

2
votes

So say I have two directories, /A/, /B/ and I have two (CI) build pipelines listening on release/*.

These two pipelines have path filters limiting them to build when the respective directory contains changes.

How would I make these build pipelines trigger when I create a new branch, e.g. release/1.7 from master? The pipelines do trigger if I omit the path filters however they do not trigger if I include them, this seems to be a "feature" introduced in https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-155-update#ci-triggers-for-new-branches

I assume the functionality exists since this workflow is what MS/AzDO do themselves: https://docs.microsoft.com/en-us/azure/devops/learn/devops-at-microsoft/release-flow

Edit: To clarity the question, how do I get back the original behavior of builds triggering when a new branch is created while also using path filters?

1
azure-devopscontinuous-integrationazure-pipelines
@Frederik what is the question? You found information why it behaves like that directly in docs :) – Krzysztof Madej
@KrzysztofMadej I'm wondering how to get the old behaviour back and since the AzDO teams seems to use the same workflow I assume there is a way to not use that "feature" since it breaks one of the most used release flows. – Fredrik

1 Answers

1
votes

Edit: To clarity the question, how do I get back the original behavior of builds triggering when a new branch is created while also using path filters?

For now the behavior you want is not supported cause that feature has partly been removed for a long time. Normally Azure Devops Service won't roll back to old behavior unless there's big issue with new behavior.

You can check the part of the history about the behavior:

2018: Some members (Issue1is not the only one) posted the feature request in our User Voice forum to remove the old behavior(new branch will trigger CI build) => 2019 July: We made changes to modify the old behavior => 2019 Aug: Some members found the behavior changed

In my opinion, one option(button in web portal) to enable/disable the behavior(whether new branch should trigger CI) could be a good choice if you do want to bring back the behavior.

So the answer to your Edited question is to post a new feature request in our User Voice forum to share your feedback. The product team would consider it seriously if it gets enough votes. Hope it helps :)