+1
It must also be possible to view the error from the UI
What do others think? Emmanuel - I know you worked on this area before
to ensure builds in error got retriggered?
Cheers,
Brett
On 31/07/2008, at 5:46 PM, Marica Tan wrote:
Ok here's my new proposal :)
SCM Errors
1. Separation of configuration/pre-build from actual build
2. Create new state for svn failure but will use ( x ) for the icon
3. Still send a notification if there's an svn failure. ( I would
still like
to be notified if something like this happens )
4. Have a checkout/update error field on the project.
5. Can release project even if it has a state of svn failure
6. Do not create a build result for transient errors
Cancelling a build
7. Cancelled build will trigger a skip but will still have it's
previous
state.
WDYT?
- Marica
On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <[EMAIL PROTECTED]>
wrote:
On 31/07/2008, at 3:54 PM, Marica Tan wrote:
On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <[EMAIL PROTECTED]>
wrote:
The more I think about it, the current (x) really signifies the
right
thing, but the way it is treated needs to be improved as you've
described.
WDYT?
You mean putting the error in the session? I think if there is a
transient
error then we put it into session so that even if you leave the
group
summary page while it's still updating/checking out and an svn
failure
occur, it's still possible to show the (x) and the error message.
But once
you leave the page again or make a refresh, the error will be gone
( we
removed the error from the session once it is displayed ) and the
status
will be the previous status of the project.
Sorry, no - I still think we should track it on the server (it's
still
relevant until it's fixed) - just not as part of the build history
for the
project.
I think we used to have a separate checkout error field on the
project - it
is probably a generalisation of that?
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
