How to find out which delivery broke the build?
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
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.
|
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 Thanks for the answer @nedgar, though I think it still doesn't solve the problem...
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
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.