Search code examples
azure-devopsazure-pipelinestfvc

Triggering a VSTS build based on change to a specific folder within TFVC

In Team Services, I'm trying to setup multiple build definitions for one Team Project that contains sub-folders for different products (following the single Team Project approach). The problem I'm having is that CI builds seem to be triggered from any change to the TFVC repo without regard to CI trigger filters.

The repo looks like:

MyProject
  Product1
  Product2
  Product3

I have 3 separate build definitions, each containing a mapping to one of the sub-folders (e.g $/MyProject/Product1) and a CI trigger with an "include" filter for the same folder.

When I checkin a change to a file in $/MyProject/Product1, VSTS starts three new builds, one from each of the three definitions. Each of the builds claims an association with the same changeset.

I was expecting one build based on the build definition containing the include filter for "$/MyProject/Product1".

A couple other things I tried:

  1. Disabling "batch changes" - still resulted in a build for each definition, but no changeset was referenced in the builds with filters for Product2 and Product3.
  2. Adding exclusion filters for parent and sibling folders - didn't see any change in behavior

The docs read:

TFVC Include

Select the version control paths you want to include and exclude. In most cases, you should make sure that these filters are consistent with your TFVC mappings on the Repository tab.

Am I misunderstanding the intended behavior of filters or is this a bug? Anyone else experience this? Any ideas for a workaround?

Note: I did look at this answer, but it is not clear to me that it covers the multiple build definition wrinkle. If you used one definition to build multiple branches and mapped a common parent, filters might not come into play.

Solution

  • This issue has been fixed now. Please try again. Refer to this link for details: CI Builds may not trigger as expected.

    Final Update: Monday, 27 June 2016 22:53 UTC

    The hotfix deployment completed on 27 June 2016 21:26 UTC and we have verified that we can no longer reproduce the issue. We understand that customers rely on VS Team Services as a critical service and apologize for any impact this incident caused.

    Sincerely, Arvin