Craig, I think you have proposed a very good solution that will fit everyone's needs. I just have one little detail to comment on. I don't really like the "set to a really high number"-solution. I think it is better to have a specific value (e.g. -1) or a separate bool to control the feature.
//P-J 2009/3/25 si <[email protected]> > > Hi Craig, > > > 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). > > +1 for me. But as I mentioned, in our edge case (svn log timeout on > intervalTrigger), it didn't stop the project once max was reached. > It certainly appears to have retried X number of times, but the end > result was just more emails and failed builds. > > If I understand you correctly, there should only be 1 publisher > notification and 1 failed build once maxSourceControlRetries is > reached. >
