Hi
for your last remark :
<quote>
To make things more confusing, the projects in
Exception status show the exception error as well as the results from
the last successful build - nunit results, etc.
</quote>
I think I can explain this :
these are results from a previous build that were not cleaned up
--> getmodifications is done before the <prebuild> tasks
so if you would clean up in the prebuild section (like I do)
and the getmodifications fail, the publishers get ran.
--> the merge publisher sees the file and picks it up :-(
so this needs some thinking into, another point on the todo list
<quote>
But once again, I don't think this exception should fail a build,
since none of the expected conditions for a build have actually been
triggered.
</quote>
A condition has been met : check for modifications, and this failed.
Now we can start endless discussions that this is part of the 'real' build
process or not,
I see your point : The build brakes for a reason that a developper van not
fix,
these errors are more for the buildmaster/system team.
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?
° ...
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?
with kind regards
Ruben Willems
On Mon, Mar 23, 2009 at 3:10 PM, si <[email protected]> wrote:
>
> Thank Craig and Ruben for the prompt response, comments inline...
>
> > maybe we should brainstorm a bit about this,
> > It would be rather easy to set a property 'PublishExceptions' or
> something,
> > which will ignore source control problems, but this is back again hiding
> the
> > problem underneath.
>
> Agreed, I knew our build server was underpowered, but didn't realise
> we were timing out, here's the stack trace if it helps:
>
> ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control
> operation failed: svn: Can't read from connection: An existing
> connection was forcibly closed by the remote host.
> . Process command: C:/Program Files/Subversion/svn.exe log svn://...
> at
> ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute(ProcessInfo
> processInfo)
> at
> ThoughtWorks.CruiseControl.Core.Sourcecontrol.Svn.GetModifications(IIntegrationResult
> from, IIntegrationResult to)
> at
> ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl
> sourceControl, IIntegrationResult lastBuild, IIntegrationResult
> thisBuild)
> at
> ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult
> from, IIntegrationResult to)
> at
> ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest
> request)
>
> > Some possibilities I see :
> > ° adjust publishers (mainly email) so it is easy to set which people get
> > mailed on what state
>
> That doesn't solve the problem where builds are failed and left with
> an "Exception" status, even though the system is able to query source
> control again.
>
> > ° hiding the exception state in cctray : show the previous build state,
> so
> > programmers only see that the build is broken when the compile does
> not
> > work/tests fail
> > and not because the network was down
>
> As per above.
>
> > Dashboard may not hide it, because it is also used to see the logs.
> > ° build in a retry amount (let's say 3 times after a sleep of 5 seonds)
> to
> > bypass real temp errors
> > (but log them in the ccnet log). Mainly meant for the schedule
> trigger.
>
> This sounds good, and it would be nice if the retry is configurable.
> But once again, I don't think this exception should fail a build,
> since none of the expected conditions for a build have actually been
> triggered.
>
> I've watched this process three times now, pretty much all of our
> intervalTrigger build projects are now in Exception status and have
> multiple failed builds as a result. They fail about 2 minutes after a
> large build in another project is triggered. Timing seems to indicate
> this is when Subversion has finished it's checkout and MSBuild has
> started compiling. To make things more confusing, the projects in
> Exception status show the exception error as well as the results from
> the last successful build - nunit results, etc.
>
> It's also a little odd though that "svn log" is timing out, as I would
> have thought a network saturation issue rather than a CPU or RAM issue
> would be the culprit, since svn is very light with respect to its
> usage of these resources. So aside from the obvious problem, there may
> be another issue in 1.4.3?
>
> thanks again,
> si
>
