Multiple projects in same repository. How to reliably trigger builds?

Builds like this can be triggered when there at least one of the files in the folder were changed even if most changes were somewhere else. If this isn't the case, we would like to ask you to open the build that got triggered, and check the "Changes" tab, and see the filelists to see whether any of them were matched. Also you can check whether the build was triggered via the trigger or maybe via some other method.

If each folder is self-contained, or at most there is some shared folders, you could use checkout rules to exclude from the builds all non-related information (or to exclusively include some of it). Triggers should honor checkout rules to determine whether there are changes relevant for the builds. (https://confluence.jetbrains.com/display/TCD10/VCS+Checkout+Rules)

We have of course checked the Changes tab, but we have not found files that match the path in the trigger.

We have for a project this trigger:

-:.
+:AnalyticsPlatform/src/InternalMicroServices/TelemetryPeriodService

and in the Changes tab 1 file changed (in 2 commits; 1 commit the branch and a merge of that branch to the master branch that the trigger is monitoring):

AnalyticsPlatform/src/ExternalMicroServices/HeatLossEdge/HeatLossEdge/DataCollector.cs

The Overview tab says this about what triggered the build:

, which we assume is the trigger starting the build based on changes in git repository.

May I ask you to send us a screenshot of the changelist plus the VCS trigger configuration? We'll need to investigate this a bit deeper to find out what's going on.

Trigger:

Overview:

Changes:

Any news on this issue?

I think the build is triggered because the merge commit 68eb0272d6dc merges some commit matched by the trigger rules. It is a known problem (https://youtrack.jetbrains.com/issue/TW-24747). Please check if adding the

teamcity.vcsTrigger.analyzeFullHistoryForMergeCommits=false

parameter to a build configuration helps. With this paramete VCS trigger will only check pending merged commits to decides whether the build should run on a merge commit.

Where can I setup this configuration line?

One place is in the Teamcity internal properties file, but we can't do that.

Is it enough to set it on the build agents? And which file is that?

Can it be even more specific? I mean, can we make this an option for a single project configuration?

You can specify it as a parameter in a build configuration. Parameter name: teamcity.vcsTrigger.analyzeFullHistoryForMergeCommits, parameter value: true.

Hmm the only parameters I can specify on a project are these (none seem to fit):

You can add it as a configuration parameter.

I have added it ad a configuration parameter, but it had no effect. It still builds even when no changes match the trigger.

But it says configuration parameters only can be used in references. Wouldn't that mean the "teamcity.vcsTrigger.analyzeFullHistoryForMergeCommits" added there would have no effect? (at least that is what we see)

Despite having added this configuration option many places, including the the \conf\buildAgent.properties file, projects with triggers are being needlessly being built. I am not sure TeamCity is going to survive managing our projects when it keeps doing that. It gives us so many frustrations.

When it adds a project to the queue, this is what it says:

So, it is added to the queue regardless of changes (seeing as teamcity doesn't know about the changes yet, just that a commit has been made somewhere in the repository).

Could it be a different option forcing a build just because a commit is made some irrelevant place in the repository?

We have 42 projects being built from the same repository. And we have to disable triggers on all of them because of the seemingly random builds that are triggered if we don't.

Found this SO issue that is quite close to our problem:

https://stackoverflow.com/questions/22111728/how-to-get-team-city-to-only-trigger-a-build-on-a-github-pull-request-if-it-cont

I am especially interested in this comment:

"In my experience this approach doesn't work. The problem seems to be that TeamCity compares the PR branch with the beginning of time when it is looking for diffs, so it will always find diffs in every directory that exists in your PR."

Is that comment true? If so, then there does not seem to be a way to have triggers on GIT subfolders in TeamCity, having it only trigger a build if there have been changes inside this folder. Can this be confirmed? Our testing seem to indicate this as not possible.

Thread from the dead

I'm having this issue, with no way to break the deadlock other than to completely delete the VCS root and re-create it. After a time the problem comes back and its rinse and repeat.

I have a single VCS root repo connection, with about 15 builds with their own unique build trigger paths

Latest version 2018.2.2 (build 61245) 

Did anyone find a cure to this? We can't go on with it this way.

There is a number of workarounds and suggestions in the issue mentioned above. (https://youtrack.jetbrains.com/issue/TW-24747). Did you check them?

@Denis Lapuente - Hi Denis, yes I have been going through the options one by one but nothing has helped so far. 

I'm wondering now if this is an issue with GIT implementation at the VSTS end and not TC at all. 

As a straw poll, I wonder how many of the issues reported above are with using VSTS ??