You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Brett Porter <br...@apache.org> on 2007/08/16 05:40:31 UTC
error states
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
Re: error states
Posted by Brett Porter <br...@apache.org>.
Anyone have any thoughts on this?
On 20/08/2007, at 10:59 AM, Brett Porter wrote:
> 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).
> 2) rebuild a project that was in error state before.
>
> 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.
>
> 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
Re: error states
Posted by Emmanuel Venisse <em...@venisse.net>.
Brett Porter a écrit :
>
>
> On 29/08/2007, at 7:48 PM, Emmanuel Venisse wrote:
>
>>> 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.
>
> agreed... can we sneak this into the 1.1 JIRA? :D
sure, I don't think we already have an issue about it (I'll search) so I'll create a new one
>
>>
>>> 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.
>
> Anything that can set an error state on the project needs to be reviewed
> to make sure it records a build result if it doesn't already - I've
> definitely found some that don't (eg, missing POM parent after scm update)
I'll check for the missing POM parent
If we have some other case, we'll fix them later.
Emmanuel
Re: error states
Posted by Brett Porter <br...@apache.org>.
On 29/08/2007, at 7:48 PM, Emmanuel Venisse wrote:
>> 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.
agreed... can we sneak this into the 1.1 JIRA? :D
>
>> 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.
Anything that can set an error state on the project needs to be
reviewed to make sure it records a build result if it doesn't already
- I've definitely found some that don't (eg, missing POM parent after
scm update)
- Brett
Re: error states
Posted by Emmanuel Venisse <em...@venisse.net>.
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
>
>
>
Re: error states
Posted by Brett Porter <br...@apache.org>.
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).
2) rebuild a project that was in error state before.
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.
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
Re: error states
Posted by Brett Porter <br...@apache.org>.
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