Brett Porter a écrit :
I think I understand this problem more now.
the svn errors are a transient problem - it occurs before a build takes
place, but they are recorded as a built result. So when they succeed
again, no build occurs because no update has taken place.
I see two possible corrections to this problem:
1) don't record a build result for update failures (have some sort of
project level error and different way of notifying/correcting).
I think it's necessary to record a build result so users know there is a
problem with the SCM connection. Continuum can't know if the scm url is wrong
or if the scm server is unreachable.
2) rebuild a project that was in error state before.
I think it's the best solution for now and won't be a lot of work.
Only the first would also address the problem of having difficulties
diagnosing errors that occur even earlier and don't record a build
result at all. It also is a nice separation of
configuration/environmental errors vs actual build failures. It helps
with the separation of roles when you have a server admin and developers
that just commit on the code.
However, it's a lot more work, and it might be better to schedule that
for the future and fix it via (2) for 1.1.
I'm agree even if I don't know yet how to find the error type.
Emmanuel
what do others think?
- Brett
On 16/08/2007, at 1:46 PM, Brett Porter wrote:
I'm also seeing where there is a "real" error, like the SVN server not
being reachable, and it not trying to build ever again.
On 16/08/2007, at 1:40 PM, Brett Porter wrote:
I see too often project's getting stuck in "error" state, and it's
quite hard to diagnose what's wrong. They don't automatically
recover, and there is no build result for the actual error (so
clicking the icon takes you to the last successful one)
Anyone have any thoughts on how we can improve this?
- Brett
