Hi
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.
Some possibilities I see :
° adjust publishers (mainly email) so it is easy to set which people get
mailed on what state
° 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
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.
other ideas are welcome ;-)
with kind regards
Ruben Willems
On Mon, Mar 23, 2009 at 5:27 AM, Craig & Sammi Sutherland <
[email protected]> wrote:
>
> Hi Si,
>
> We realise this is an issue, it was added in the 1.4.3 release. Basically,
> in previous version, source control errors were ignored (totally), which
> was
> not good. However, the new approach has now gone the opposite way and
> raised
> too many issues!
>
> We are going to make some changes around how the exceptions with source
> control operations are logged - hopefully this will be in the next release.
>
>
> Craig
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of si
> Sent: Monday, 23 March 2009 1:23 p.m.
> To: [email protected]
> Subject: [ccnet-user] Re: sticky exception status
>
>
> After a little more investigation, the projects in "Exception" status
> will successfully rebuild after a commit has taken place (projects
> have intervalTrigger) or as reported before a build is forced.
>
> However, it doesn't seem right that a build should be failed even
> though there was no trigger condition activated which led to the
> failure. It also points to changes between 1.4.0 and 1.4.3 causing
> this behaviour.
>
> FWIW, after watching this unfold for a second time, the "svn log" time
> out seems to be due to a resource issue on our build server, rather
> than a comms issue between servers. I realise this isn't a fault with
> ccnet, but figured it might be worth mentioning.
>
> cheers
> si
>
> On Sun, Mar 22, 2009 at 7:32 PM, si <[email protected]> wrote:
> > Greetings,
> >
> > I've run into an issue where communication between our (virtual)
> > servers hosting ccnet and svn was timing out for a few minutes, and
> > when it has come back up again, some of our ccnet projects have
> > remained stuck in the "Exception" status thrown by ccnet call to svn
> > log. The only way to resolve is to force a new build of the projects,
> > and obviously this isn't ideal when we have lots (and lots) of
> > projects.
> >
> > Perhaps ccnet (can) perform a retry for a certain number of iterations
> > (with an increasing time delay between attempts) and then gives up?
> > Not sure, I couldn't find anything in my local copy of the documention
> > and confluence.public.thoughtworks.org is currently down.
> >
> > I upgraded ccnet to 1.4.3 on Friday, but I'm not sure if this issue
> > was present in our previous version (1.4.0).
>
>
