3

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.

Community
  • 1
  • 1
Seth
  • 112
  • 9
  • 2
    This is a bug with VSTS, I can get the same behavior with you. I have help you submitted a feedback on MS connect page, you can track the status here: https://connect.microsoft.com/VisualStudio/feedback/details/2847213 – Eddie Chen - MSFT Jun 23 '16 at 01:03
  • I just hit the exact same problem. In my case it isn't multiple projects in a single repo, but different branches of the same project and different builds for each branch. I'll try to filter for files as well instead of just branch path to see if it works. Fingers crossed! – Kelps Sousa Alux Jun 24 '16 at 12:55
  • filtering with files also didn't work :( – Kelps Sousa Alux Jun 24 '16 at 13:34
  • @KelpsLeitedeSousa This issue has been fixed now. – Eddie Chen - MSFT Jun 28 '16 at 05:00
  • @EddieChen-MSFT I am seeing the same problem: in a signle-repo scenario, a commit to a branch will trigger a build even if the changed files are under an explicitly excluded path – Marcello Romani Dec 21 '17 at 13:15

2 Answers2

2

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

Eddie Chen - MSFT
  • 29,708
  • 2
  • 46
  • 60
1

I believe I found the bug! Looks like the build definition triggers for the build are not respecting the mapping, but they used to a while ago. I used the history and did a diff in 2 of my build definitions and the json for one (the older build definition) had the full branch path defined in the mapping set in the branchFilters for the trigger, but the new branch definition only has the repository path in the branchFilters, even with the repository mapping pointing to the branch.

old and correct build definition:

"triggers": [
{
      "branchFilters": [
        "+$/WF.Workflow/Main/!v09"

new build definition (wrong and runing for every checkin in the repository)

"triggers": [
        {
      "branchFilters": [
        "+$/WF.Workflow"

this new one should be pointing to "+$/WF.Workflow/Main/!v08"

I added a comment in the Connect issue created by Eddie with this information. I hope it helps.

As a temporary workaround I tried to use Gated CheckIn and it seems to work for now. It adds some bureocracy to the checkin process, but it is all I could do for now. I hope this get fixed soon.

Kelps Sousa Alux
  • 486
  • 6
  • 6