It's all about the answers!

Ask a question

How to find out which delivery broke the build?


Rafael Rezende (431123) | asked May 14 '14, 11:59 a.m.
In order to find out which delivery broke the build, a potential solution would be then to trigger one build after each delivery. This question is better described in the following issue:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=308841

It has been suggested to use Personal builds instead, so that every developer can request its own personal build, running on the build server, before delivering the change sets.
This is a very interesting feature, indeed! However, I believe it doesn't solve our problem because the builds in this case aren't cumulative.

Our builds take few hours each, and it would happen very often that a developer A requests a Personal build while developer B is already running his one. When A's build finishes, B would have already delivered his change sets, so that A would be required to accept them and request a personal build once again (change sets from A or B alone may not break the build, but together they can break it.). In a larger scale (+ developers, + build duration) it would be difficult to manage.

Instead, we need change sets from dev A to be available to every other developer (that is, delivered) immediately before his build starts. So, when dev B is ready to deliver, he will first accept the incoming change sets (which could be green or not) and deliver the merged code. A build with change sets A+B would be queued right after the build with change sets A.

Is there any strategy to solve the issue above?

2 answers



permanent link
sam detweiler (12.4k6172200) | answered May 14 '14, 4:50 p.m.
 I don't think you can find out which 'deliver' caused the problem, but you should be able to see the change history for the file that is causing the problem. 

permanent link
Nick Edgar (6.5k711) | answered May 15 '14, 12:41 p.m.
JAZZ DEVELOPER
One approach is to set up an intermediate 'staging' stream, with a corresponding build.  You can then set up post-build deliver in that build to deliver/promote the accepted changes to the "real" integration stream but only if the build is green.  That is the original use case for post-build deliver.

Comments
Rafael Rezende commented May 20 '14, 12:11 p.m.

Thanks for the answer @nedgar, though I think it still doesn't solve the problem...
The main idea isn't to keep a green stream, but to identify which deliver broke the build.
For instance, if we have a polling of interval N, and 5 deliveries are performed in a single interval, the next build request will include the change sets of all those deliveries...
If it breaks, we still don't know which delivery caused that, no matter if the post-build delivery in staging stream was triggered or not.

A delivered. A was built successfully
B delivered. A+B was build successfully
C delivered. A+B+C build failed... something is wrong with the latest change sets from C OR with the merging process from the stream to C.


Nick Edgar commented May 20 '14, 4:23 p.m.
JAZZ DEVELOPER

In your example, it would be clear that C was the cause of the failure. The post-build deliver doesn't do a merge -- it does a replace of the component(s) into the target stream.  Your point about multiple deliveries within the timeframe of a single build is still valid though, and there could still be other integration issues though, e.g. if multiple builds are pushing to the integration stream for different components.


As Heather points out in the work item you filed, we would need more control over SCM snapshots and the ability to load from them directly to be able to run a new build on each delivery.

Your answer


Register or to post your answer.