teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch=true seems not to work


I am using TeamCity Professional 2023.11 (build 147331). 

My problem:

There are 2 branches “develop” (== <default>) and “master”, where we only get commits on master by fast forwarding from develop. I have set a build trigger for both of them.

Adding a commit to develop will trigger a build (as expected). When then fast forwarding this commit to master, i don't see a build triggered for master branch. 

I already found, that it is likely not triggered because it is no new commit due to fast forwarding. So i started playing around with teamcity.vcsTrigger.runBuildOnSameRevisionInEveryBranch=true parameter.

I added it as a configuration parameter into my build plan, which didn't trigger a build as expected.

I also added it as a custom parameter into the vcs trigger, which also is not triggering a build.

Am i doing anything wrong?

I am grateful for any help.


1 comment


Actually, this parameter is true by default, so explicitly configuring it is redundant (although it might be helpful if you intend to modify this behavior in the future, it's not obligatory). We also have a feature request to incorporate it as a dedicated UI setting rather than a custom parameter, and we are actively working towards making it functional for the default branch as well: YouTrack Issue: TW-29822.

The core issue in your scenario seems that the merges are fast forwards with the commits already built in the default branch. The default branch is treated as a special case, not just as another branch. Consequently, when the trigger reviews pending commits to build, it doesn't identify any, as they were already present on the default branch.

The simplest 'workaround' would be to shift the default branch to another one that wouldn't trigger this behavior, while ensuring 'develop' is included in the branch spec if missing (although I suspect it's already there, it's worth confirming). With this configuration, the parameter would have built all the revisions, as the trigger would have recognized commits in the branch not built on either its branch or the default branch.

Alternatively, preventing fast forward merges would also be beneficial here. This way, the new merge commit would be entirely new, ensuring that the new state of the branch is built for certain, even if the commit hash is slightly different.

Hope this clarifies the situation.


Please sign in to leave a comment.