Sounds like a great plan that should be configurable enough to make everybody happy.
Thank you! Jon On Wed, Mar 25, 2009 at 11:59 AM, Craig Sutherland <[email protected]> wrote: > > Hello all, > > I've been looking into this issue and seeing how we can improve > things, since it obviously is a contentious issue. > > First, what we were trying to achieve: previously errors with source > control were ignored or they would just crash the server. Obviously > this state was not particularly good. The changes now include source > control operations errors as build exceptions. Unfortunately, this now > appears to have gone the other way and made CC.Net too sensitive to > issues with source control. > > So what I am planning on doing is adding some tolerance to the > process. There is already a project setting called > maxSourceControlRetries, which currently sets the allowed number of > source control failures before stopping the project. > > What I am going to do is modify the source control checking, so if get > modifications fails, it only logs the error (similar to pre-1.4.3). > However, it will count the number of failures - if the number of > failures reaches the value in maxSourceControlRetries (by default this > is five), then it will log an error, change the build status to > exception and stop the project. If this state occurs, it will also run > the publishers to send out any e-mails, notifications, etc. > > This way people now have some control over the sensitivity of source > control checks. If you want to completely ignore this feature, set > maxSourceControlRetries to some really high number (it's an Int32 > though, so not too high), or if your source control/network/etc. is > really, really good and you don't except any problems, set it to a low > number (e.g. 0). > > What do people think about this approach? > > > Craig > > On Mar 26, 2:33 am, Jon W <[email protected]> wrote: >> On Tue, Mar 24, 2009 at 9:19 PM, si <[email protected]> wrote: >> >> >>> 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 ;-) >> >> > Of course, and choice is good! >> >> > Anyway, I took Ruben's advice about setting up a single queue for all >> > our projects, and that should resolve the problem. >> >> > I'm still not completely convinced that the underlying cause (svn log >> > timeout) was due to the server or network, it may well be, but if more >> > reports start coming in then there might be some other issue at work. >> >> I agree with Si. I would like the svn timeouts to be logged just as >> they were pre-1.4.3, but I don't think the builds should enter the >> failed state due to a 'checking for modifications' action. An >> administrative notification can be sent, but that should only notify >> the administrator of the build system, and not the 100 developers who >> only need to focus on code modifications. >> >> Thanks, >> Jon
