> 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 ;-)
