We have over 150 projects which I have gathered together, reconfigured and optimised into multiple TeamCity configurations, with multiple build agents, to try to improve our build server performance which currently builds in a highly sequential manner.
The mix of technologies (Web, dotNet, VB6 and COM+) and system architecture means that there are various steps (configurations) which can now run in parallel but which need to come together further down the track.
This is a very simplified dependency scenario but representative of a problem we have....
A -> B -> Collate (-> Deploy)
A -> C -> Collate (-> Deploy)
The issue is that, if a change is made to A, it will result in B and C both triggering which will result in the Collate (and Deploy) steps running twice, despite being a common trigger in A. As I say, this is a simplification of the real set of almost twenty configurations and the frequent rebuilds are impacting the speed improvements.
Can anyone suggest any way that I can identify the fact that both B and C will be triggered as a result of A and make the Collate step wait for both B and C to complete before triggering the Collate step? Obviously a change to B or C should be able to trigger the Collate independently.
I'm new to TeamCity, but I believe that this is what you need:
A: no triggers or dependenciesBandC: no triggers, snapshot dependecies onACollate: VCS trigger, snapshot dependency onBandC
With that setup, a VCS single push will result in:
- exactly one build of
A,B,CandCollate Abuilt beforeBandCBandCbuilt beforeCollate- all built from the same point in VCS
If you want to pass artifacts down the chain then you will need to define artifact dependencies as well.
If the different builds use different VCS repositories, then you still should not set VCS triggers on A, B and C; instead you set the “Trigger on changes in snapshot dependencies” option on the VCS trigger for Collate.
来源：https://stackoverflow.com/questions/19806689/trigger-subsequent-build-once-after-multiple-parallel-builds-in-teamcity