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?

Votes

0

Share

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.

We have a c++ framework project (one VCS) containing multiple sub libraries in sub directories. And we have a single project in teamcity for each sub library as you mentioned in the second paragraph. When a commit changed a sub library, we detected it by "Trigger rule" filtering sub directory and fire a super dependency build teamcity project with changed library name. This works fine.

But sometimes a single commit may change multiple sub libraries at the same time. How can we inform our super teamcity dependency project with the names of all changed libraries?

As I said before "We have a c++ framework project (one VCS) containing multiple sub libraries in sub directories.". Assume that A,B and C sub directories (libraries) and assume that D,E and F libraries each depends on A,B and C. If a change occurs in A, B or C, dependent projects D,E and F should be triggered to build.

Assume that a single commit has changed all A,B and C subfolders at the same time. This will trigger D,E and F projects 3 times. But I need to build once.

Do you mean that D, E and F are triggered three times each? So to make sure I understand it. You have something like this:

A -> D

B -> E

C -> F

If you have the VCS Triggers on D, E and F, with the appropriate restrictions (adding the trigger rules for their respective folders), then only one of each should be triggered whenever a commit with changes on all three arrives.

If this isn't happening on your end, please share with us screenshots of the vcs triggers and any dependencies in the build configurations

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.