My opinion: an error is an error... either the build succeeds or it fails, and some form of notification should be sent for all errors. It's a binary choice - the "Failure" status should cover all errors. The question is then reduced to "who do you notify on what failure condition?"...
Perhaps ccnet could do something like: * create the concept of "error notification categories" which could be assigned to individual tasks... which can be configured as required. In fact for bonus points, you could assign different categories to different error conditions on the same task (use the exit value, parse error output for HResult, use RegEx to check stack traces for particular exception text, etc.) * assign error notification categories to the email groups. Obvious split is "build task" failures (to dev) vs "ccnet process" errors (to buildmaster), but this sort of setup could be configured as required. * A default category should catch anything not explicitly configured. Those of us who have reliable connections to our source control are probably quite happy for "process" errors to go through to the devs (eg. if they break the build config, take a testing resource offline, etc.) and shouldn't need to modify our configs if we only need the one "default" category. * Some tasks may need a little work to add options for robustness (configurable timeouts & retries). Cheers, - Sam. On Mon, Mar 23, 2009 at 10:41 AM, si <[email protected]> wrote: > > > Suppose we do not fail the build, not go to exception state, what do you > > want the state to be? > > ° the same as the previous? > > ° ... > > I'm happy for the state to be Exception, but not for the build to be > failed**, and the Exception state to be maintained only while ccnet is > failing because of a trigger exception. > > ** The current implementation of ccnet 1.4.3 means that "Last Build > Status" has two different meanings, the normal meaning, and the "I had > an error talking to source control checking an interval trigger", > which in fact may be perfectly fine now (as per our situation) and > doesn't IMHO relate to the last build status in any way. > > I have no problem with my intervalTrigger builds waiting until the > other (in our case more important) build has completed. After > re-reading the release notes, I see you have maxSourceControlRetries, > so I will bump this up and see if it helps us, sorry I missed this > before posting. > > I certainly don't want to get into an endless discussion about build > process semantics, but couldn't this be left up to each user of ccnet > to decide for themselves? Provide a (per site/project/trigger) > configuration option, something like > "failBuildOnIntervalTriggerException". As per your previous > suggestion, having a publisher for such exceptions would also be good. > > > we must be sure that we do not introduce another problem here : > > Situation : > > ° dev A checks in > > ° CCNet checks for modifications > > ° getModifications has an error > > ° because of setting X-Y-Z, we show the previous state, which was ok > > > > ==> dev A thinks : great : my commit works > > > > but it never was compiled/tested. > > how would we make sure that DevA knows that his commit has not gone > through > > CCNet yet? > > I see your point, but using my current situation in your example - for > the period where ccnet is unable to talk to svn, the project state > would be "Exception", so no build should take place as the trigger > hasn't successfully run. Once communication between ccnet and svn is > restored (intervalTrigger is successful), svn log will show changes > and trigger the build, thus resulting in a proper build result. > > What i'm not sure about is what should happen if the someone forced a > build or scheduled a build during the time a project is in "Exception" > state? Should you be allowed to? But then how do you recover from > Exception state? Hmmm, I can see how tricky this stuff is! > /starts slowly backing away from minefield ;-) >
