Temcity, how to define which VCS had triggered the build

In my Teamcity build configuration I have three VCS configured: VCS configuration

If any of those would have a check-in - the trigger would fire and my build would be running.

What I need to know - which from those repositories had fired the trigger. What I can know is the type of the trigger event: echo %teamcity.build.triggeredBy% (in case if the build was triggered automatically it would say "GIT") , however, I don't' see any option to know which VCS had triggered the build.

Any thoughts how this could be achieved?


Hi Pavel,

Currently it's not possible to determine which VCS root triggered the build in TeamCity. Why do you need to get this information?


I have three different APIs, and want to deploy only that API, repository of which was updated (and triggered the build this way).


I have the same problem. I think in the world of microservices, when each service has its own repo, this is a must have feature for Teamcity!!! This is not a big deal to add builtin parameter which will provide information on a vcs name which triggered the build configuration. Instead of creating a tens of build configuration we can add multiple vcs roots to a single build configuration and depending on this parameter change build flow.


Hi Dinar,


without dismissing that it might be interesting, it does miss a factor: A build is not necessarily triggered by a single commit on a single VCS Root. If 2-3 commits come to different repos at around the same time, TeamCity might pick them all up at the same time and trigger a build with it. In that case, that build would not have been triggered by any VCS Root in particular and all would need to be reported.


In the meantime, we are of the opposing view for your use case. Requiring a single build to have a long script with logic within it in order to decide what to do depending on which VCS Root has triggered is counterproductive. It's much easier to have a template that contains all the shared code, then simply create new builds based on that template and simply adapt the parameters. Reduces substantially the possibility to introduce errors in the logic, while increases visibility, scaling up much better than a script. You know instantly what has been triggered (because it's a different build configuration) instead of having to dig through the log to see what has been built/deployed.


Please sign in to leave a comment.