History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: QB-526
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Robin Shen
Reporter: AlSt
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Allow to propagate changes from a dependent build (in)to the depending build for complete/aggregated notifications

Created: 05/Feb/10 07:50 AM   Updated: 05/Feb/10 01:34 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Original Estimate: Unknown Remaining Estimate: Unknown Time Spent: Unknown

 Description  « Hide
Build A depends on build B (or in fact on artifacts published by build B), and while build B was successful, build A failed. The failure is caused by changes in the sources checked out by build B and handed over in some shape to build A via the published artifacts. As a result, the actual culprit was not notified, since the failure-causing sources were not checked out by build A, but only in build B; and the notification was obviously sent from build A.

Add a flag (most probably in either the repository specification of build B, or in the repository's corresponding checkout step of build B?) that optionally allows to propagate changes to dependent builds -- so that the actual culprit is notified (too).

 All   Comments   Work Log   Change History      Sort Order:
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.