Multiple, triggered builds are seemingly non-deterministic in order

Because I trigger builds on VCS check-in and have build chains, some projects are built multiple times because of a single check-in.


- A
- B
- C
- D

B and C have build dependency triggers for A

D has a trigger for C

A,B,C,D have VCS triggers

When I check in a changes for A,B, and C at the same time it causes them to all build in a seemingly non-determinsitic order. Eventually everything is sorted, but the notion of a Quiet Time for VCS check-ins (set to 60 seconds) doesn't seem to apply to triggered builds. Is there a way to tell the builds to wait 60 seconds before starting so that some sort of algorithm can be applied to figure out the most efficient build order? I know this is an NP problem, but it isn't *that* hard. After 60 seconds all the builds in the queue should be arranged based on the build dependency map. That seems fairly straightforward.

Or am I missing something?

On another note, is there a way to control the number of concurrent builds allowed on a build agent? I would like to guarantee at most one build at any given moment.


1 comment

Build agent can run one build at a time only. There is also setting to control how many builds of a single build configuration can be run simultaneously (the setting is on the build configuration general settings page).

Build dependency triggers do not guarantee order. They just add builds to the queue, nothing more. If you need to define specific order you probably need to use snapshot dependencies.
If B and C depend on A and D depend on C, you can define it with help of snapshot dependencies:
D -> C, B -> A and C-> A
Then you can add VCS trigger for, say, D and make it watch changes across dependency graph, in this case if a change is detected in A, TeamCity will add D, C and A to the queue. And builds will start in this order.


Please sign in to leave a comment.