> I now have 7 projects in "Exception" status (which are actually > running) with failed builds and none of them have actually failed, > they only failed because our server wasn't able to query svn because > another build appears to have saturated available resources on the > server..
...and that's where our opinions differ: I see the situation as an actual failure - if you aren't able to guarantee a successful build in a timely fashion, it's a failure (along the lines of a typical "enterprise" SLA)... just a question of filtering different failure notifications to different people based on the cause. But then my opinion is just one of many, and everyone is entitled to their own ;-) Cheers, - Sam. On Mon, Mar 23, 2009 at 10:29 PM, si <[email protected]> wrote: > > Hi Sam, > > > My opinion: an error is an error... either the build succeeds or it > fails, > > Except the build was never actually triggered, it failed because the > trigger to test build conditions failed. > > I now have 7 projects in "Exception" status (which are actually > running) with failed builds and none of them have actually failed, > they only failed because our server wasn't able to query svn because > another build appears to have saturated available resources on the > server.. > > ... > > * Some tasks may need a little work to add options for robustness > > (configurable timeouts & retries). > > And that's all I really need to handle this edge case; improved > robustness for the intervalTrigger, although a separate publisher for > trigger-based exceptions wouldn't go astray. >
