continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <emmanuel.veni...@gmail.com>
Subject Re: refactoring the SCM
Date Thu, 07 Aug 2008 20:32:54 GMT
+1 but few comments

On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ctan@exist.com> 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


In my vision, the icon for svn failures shouldn't be on the project, maybe
on the group.
With a scm failure, Continuum can't start the build so the project state
don't change

>
> 3. Still send a notification if there's an svn failure. ( I would still
> like
> to be notified if something like this happens )


Yes, but without a project context (project name, build definition), It
should be a general message and sent only one time for all projects. I don't
want to be spammed by the same mail for all modules.

>
> 4. Have a checkout/update error field on the project.


I don't think it is the best place. A new table with the list of all scm
root address with a state on each would be probably better.


>
> 5. Can release project even if it has a state of svn failure


With a scm failure, the release process can't run, you must check if the scm
is back or not.

>
> 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.


what do you mean?

Emmanuel

>
>
> WDYT?
>
> - Marica
>
> On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <brett@apache.org> wrote:
>
> >
> > On 31/07/2008, at 3:54 PM, Marica Tan wrote:
> >
> >  On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <brett@apache.org>
> 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
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message