Robin Shen [05/Feb/10 08:00 AM] This can be achieved by adding a "trigger another build" step in build B to trigger build A and set the wait flag as "true". If the trigger step fails (which means build A fails), build B is considered failed and build notifications are sent to its committers. With proper scripting, you may even let build B successful in this case, but still send out notifications to build B's committers if that trigger step fails.

AlSt [05/Feb/10 11:27 AM] I am not sure if I understand it correctly and therefore try to show my (!) example in other words; I have the feeling that your example is swapping A and B, which may cause my confusion: There are in fact n builds called A1..An that all depend on build B. Build B does not fail. One or many of builds A1..An may fail => one or many of builds A1..An must send a notification to the culprit who in this specific case made a change in a repository checked out by build B (and not by any of builds A1..An). Are you suggesting that I should replace the checkout step from build A1..An (that implicitly triggers build B -- configured with "latest build (generate new if necessary)") with "trigger another build" set to config of build B? And this implicitly solves the complete/aggregated notification problem?

Robin Shen [05/Feb/10 11:52 AM] No, the "trigger another build" steps should be added to trigger A1 through An when define steps of B, so that all projects using B's artifacts will be verified as part of B's build process, and B will send failure notification to its committers if one of them is failed. In future version we will add a step called "trigger dependents" to analyze the dependency graph and automatically trigger all configurations actively depending on current configuration.

AlSt [05/Feb/10 12:28 PM] Thanks for your patience and enlightening. Now everything is clearer, but in our mind the "trigger another build" has another limitation for our use case: If a user is only interested in Ax and he therefore triggers only Ax, then the notifications will not be aggregated. Unless the dependency via QB repository triggers B that in turn triggers Ax -- however, this would then also trigger A1..An, which is much more than the user wanted. (In particular if each of A1..An takes quite some time to complete.) An additional problem by this one-to-many triggerings can be the currently chosen queue size restriction ignorance within triggering chains: We think it might make a lot of sense to add at least a flag to allow adhering the queue size restriction in trigger chains. If dead locks due to limited queue size are then happening, there is solely a configuration problem that can most likely be solved by splitting a queue up in two or more queues, and/or the queue size was really set too small. => If this makes sense to you too, would you mind taking this on board of your release plan? The new step called "triggered dependents" has in our mind obviously the same risks by triggering potentially many other builds and thus the queue size restriction ignorance comes into play. Of course, here is also where QB2.1's new resource management is said to be applicable, but configuring the queue is definitely easier and more apparently presented in the GUI.

Robin Shen [05/Feb/10 01:34 PM] What you described does make sense. We will take this improvement into account for future releases.