Hi
the showing of source control errors is indeed a big change, from 1.4 onwards. There are pro's and con's. >From my point of view, every error should be visible clearly, and not just logged away somewhere. For example : you have a nightly build, and there was a source control error --> previously you would think all is ok, because the build is still green. now just suppose some guys from the IT department changed the backup procedure without notifying, your nightly build could be wrong for days/weeks before you notice it. To prevent these things, the errors are shown, and people have now the choice what to do on source control errors. If you want to 'keep' the same behavior as before, you can set the maxSourceControlRetries to a high number 60.000 or so, and the sourceControlErrorHandling to OnlyReportOnReachingSourceControlAmount (do not know the exact enum description by head) I do not advise this though, if you know the backup is taking place between 22:00 and 23:00 it is best to use a filter trigger with kind regards Ruben Willems On Tue, Aug 4, 2009 at 7:12 PM, PilotBob <[email protected]> wrote: > > On Aug 3, 3:48 pm, Ruben Willems <[email protected]> wrote: > > Hi > > > > this seems like a temporary network error, or your svn repo was down for > a > > short while > > check the options > > sourceControlErrorHandling > > maxSourceControlRetries > > I see this issue alot now too. I assume it is happening when our > repository is being backed up. > > The thing is I never saw this with 1.3.x IIRC. It only started > happening with 1.4. I am not sure why the build would show as failed > if there was an issue with CCNet talking to subversion server. > Actally, I am wrong, this started happening with 1.4.3... and I see in > the 1.4.3 release notes it says: > > Previously when there was an error during the GetModification stage, > there was only a log on the server level and the build was considered > good. This has been changed so the build will now go into the > 'Exception' state. The project will still be running and continue to > check for modifications. By default, CCNet will tolerate 5 consecutive > errors but will stop the project on a 6th error. At that point someone > will need to intervene to clear the error and restart the build. The > number of errors recorded before stopping the build is configurable by > changing the project level 'maxSourceControlRetries' attribute in the > configuration file. The email publisher can be configured to send > mails for each error recorded. > > Frankly, I liked the "previously" behavior just fine. is there any way > to revert to it? > > Ok, maybe not. What I would like to see is that the build status > doesn't go to error status... there is nothing wrong with the project > itself if there are source control errors, right? Is it possible for > it to Stop the build, send a notification to buildmaster but NOT show > the build as "Exception" status since the tasks are never actually > run. In this situation. > > BOb >
