I agree with Brad, "It wouldn't be the most intuitive result." I can see why the labeller could be a problem :-(. But being able to "Abort" a build process quickly and cleanly seems to be a basic requirement, notifying the build master would make sense (or a predefined group filtered on notification type) but I don't think the rest of the team (30+ programmers in our case) would appreciate this piece of information.
One of the other 'Abort' related issues that I noticed is that selecting the "Abort" button seems to abort the current TASK not the whole build... I found myself having to click the "About"/"Refresh" buttons 5 times in a row on friday to try and abort a Project Triggered task that had triggred due to a failed project in development. Both which then emailed everyone to let them know that the two projects had failed! Doh. I know I should have removed them all from the email publisher, but I forgot. It was late Friday and I wanted to go home. On 13 Feb, 19:33, Ruben Willems <[email protected]> wrote: > Hi > > Maybe we can also foresee an integration status aborted, > but this is more work than it seems. > > for instance the labellers, we need to check the logic so the numbering is > still ok > they need to threat this newly aborted code as a failed one. > and there are also other area's we'll need to look into. > > with kind regards > Ruben Willems > > On Fri, Feb 13, 2009 at 8:26 PM, Brad Stiles <[email protected]>wrote: > > > > > > would setting a aborted build to the state of exception be ok? > > > This state can occur when there is some real unexpected problem in the > > flow > > > of the integration, an error in getting the source for example. > > > It wouldn't be the most intuitive result, at least not to me, unless > > there was a specific exception message that mentioned "build was > > aborted" or something similar.
