Azure-devops-docs: Path filters ignored on 1st push to new branches for CI builds

[philip-reed]

I had a weird issue that I don't think is explained above.
If you have two build definitions defined with CI triggers enabled as follows:

# Build Def A
# Only want this build to trigger if something changes under docs/A
trigger:
  branches:
    include:
    - master
    - users/*
  paths:
    include:
    - docs/A/*   

# Build Def B
# Only want this build to trigger if something changes under docs/B
trigger:
  branches:
    include:
    - master
    - users/*
  paths:
    include:
    - docs/B/*   

Then create a new user branch and push something to it with a change under docs/A/, both builds are triggered.
Presumably this is because both docs/A & docs/B have been created and this is considered a change.
Subsequent changes under docs/A/ only trigger Build A as expected.
Not sure if this is expected behaviour?
If it is expected behaviour, how might someone prevent all of the builds triggering for each 1st push to a new branch? This is in the context of having multiple projects/solutions in a single repository, which i'm not sure is best practice.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f5673ec1-c7d1-e0ac-043a-8fc3d5b226a9
• Version Independent ID: b4872831-51c0-6cf8-1c56-de20beb38a80
• Content: Build pipeline triggers - Azure Pipelines
• Content Source: docs/pipelines/build/triggers.md
• Product: devops
• GitHub Login: @andyjlewis
• Microsoft Alias: alewis

[simonness]

Monorepos should be supported, there are even MS tutorials out there that use them 👍

From Developer Community:

Thank you for your suggestion! This is a known limitation of how we handle new refs. Creation of a new ref is handled as if the code changed in all paths. We have an item on our backlog to compare what changed in the ref compared to the parent it originated from.

[MattMencel]

Is there any progress on this? I have several dozen builds configured in a monorepo... my triggers are configured like this...

trigger:
  batch: true
  branches:
    include:
      - master
      - feature/*
  paths:
    include:
      - 'PATH/TO/BUILD/CODE'

When I push code to a new feature branch, instead of just building for the included build path, it runs every build in the repo.

This happens before the merge to master, and there are no build validation policies specified on feature/* in the repo.

On subsequent pushes to the now existing feature branch, it doesn't trigger any build storms.

Is there a workaround that can be used in the meantime?

[benjsherman]

My team is in process of migrating each project to its own repository. But in the meantime, this is an issue. I wonder when we can expect the fix.

[BlairMcc]

I am encountering the same issue here.

Dev lead created a new release branch and now it has kicked of all of our builds. I will probably just remove release from my branch filter

trigger:
batch: true
branches:
include:
- 'master'
- 'develop'
- 'release/'
paths:
include:
- 'Path/To/Code/'

[FlexiGit]

Although I lived with this behaviour since the arrival of git to TFS, I would very much prefer that NOT every build will be kicked off after branch creation.
This is especially true, if every build kicks off a release pipeline.

[BlairMcc]

This looks like it has been fixed in AZDO sprint 155

Now, we have a better way of handling CI for new branches to address these problems. When you publish a new branch, we explicitly look for new commits in that branch, and check whether they match the path filters.

https://docs.microsoft.com/en-us/azure/devops/release-notes/2019/sprint-155-update#ci-triggers-for-new-branches

[nprieto95]

My team and I were relying on the previously existing behavior for one simple reason: the "Download Artifact" task does not let you specify fallback branches, so when we wanted to run a build which used all of our artifacts from a specific branch, all of them needed to have a build run at least one time for the desired branch.

This worked before because new branches had all their builds run at least once. Now for new branches we have some builds running and some builds not running, depending on where in the application the changes were made.

For now I told them to manually trigger the rest of the builds to be able to run the pipeline that depends on having all of them built.

Do I have any way to turn this new behavior off for my organization? If not, what is the suggested workaround to avoid having them manually schedule 5 builds every time a new branch is created?

Just an edit: I want to make clear that ideally I would want an option to fall back to master as the default branch to download the artifact from when no builds are available from a specific branch, but my understanding is that this would be a new feature which would require a much bigger effort and it is a dependency we can not afford to rely on.

[bremnes]

@nprieto95 , might be a hackier workaround than you ideally want, but how about setting up a service hook?

You can subscribe to the build/release definition in question, and then in your service hook-processor (azure function?) queue the builds automatically for the branch in question if the build/release fails.

[vijayma]

Working on updating the docs to clarify this.

[vijayma]

Thank you for your feedback.
The article has been updated to clarify this. This has been a popular ask to honor path filters when pushing new branches, and we are glad that we have been able to complete that work.