You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Marica Tan <ct...@exist.com> on 2008/07/30 04:06:30 UTC
Re: refactoring the SCM
Hi All,
I would like to work on the transient state.
Here's what I'm proposing to do:
1. Add two new states: SVN_FAILURE and BAD_POM
* thought of adding just one state: TRANSIENT_ERROR but it's not
descriptive
2. When an error occur due to svn failure or bad pom configuration then
a. create a build result and set the state to #1
b. retain the old state and latestBuildId of the project ( before
building / updating )
3. Add a new status icon for transient errors. ( No idea yet how it will
look like. Any suggestions? )
4. In the ProjectGroupAction#summary class:
a. check if there is a build result having SVN_FAILURE or BAD_POM state
b. if exists, put it in the session for 5 mins and delete the build
result from the database.
c. if not, check if it's still in the session
d. set project state = build result state
e. display the state and associated error message
WDYT?
Thanks,
Marica
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Wed, Aug 13, 2008 at 2:52 PM, Maria Odea Ching <oc...@apache.org> wrote:
> (Sorry, I just caught up now with discussions here in the list..)
>
> +1 on the proposal..
>
> On Fri, Aug 8, 2008 at 4:32 AM, Emmanuel Venisse <
> emmanuel.venisse@gmail.com
> > wrote:
>
> > +1 but few comments
> >
> > On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@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
> >
>
Is this one svn state for the whole group or per scm root?
>
> > >
> > > 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.
>
>
> +1 to Emmanuel's suggestion
>
>
> > >
> > > 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.
> >
>
Will it be ok if we also move the scm result to a project level, so a
project will have an scm result and a build result? Right now, the scm
result is dependent on the build result, which should not be the case.
>
> >
> > >
> > > 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?
>
>
> I think this is for a project currently being built? If the build's
> cancelled, the previous state (e.g. before the cancelled build) would be
> retained?
>
> Yes
Thanks,
Marica
Re: refactoring the SCM
Posted by Maria Odea Ching <oc...@apache.org>.
(Sorry, I just caught up now with discussions here in the list..)
+1 on the proposal..
On Fri, Aug 8, 2008 at 4:32 AM, Emmanuel Venisse <emmanuel.venisse@gmail.com
> wrote:
> +1 but few comments
>
> On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@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.
+1 to Emmanuel's suggestion
> >
> > 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?
I think this is for a project currently being built? If the build's
cancelled, the previous state (e.g. before the cancelled build) would be
retained?
>
>
> Emmanuel
Thanks,
Deng
Re: refactoring the SCM
Posted by Emmanuel Venisse <em...@gmail.com>.
+1 but few comments
On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@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 <br...@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 <br...@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/
> >
> >
>
Re: refactoring the SCM
Posted by Olivier Lamy <ol...@apache.org>.
2008/7/31 Marica Tan <ct...@exist.com>:
> 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 )
IMHO should be configurable ? (off by default ?) (if configurable
global configuration or per projectGroup ? )
> 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 <br...@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 <br...@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/
>>
>>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
+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 <br...@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 <br...@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/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
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 <br...@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 <br...@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/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 31/07/2008, at 3:54 PM, Marica Tan wrote:
> On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@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/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@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.
- Marica
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
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?
- Brett
On 31/07/2008, at 9:21 AM, Marica Tan wrote:
> Hi Brett
>
> Do I still need to add new status icon for transient errors?
>
> Thanks,
> Marica
>
> On Wed, Jul 30, 2008 at 2:58 PM, Brett Porter <br...@apache.org>
> wrote:
>
>> Hi Marica!
>>
>> I like the idea, though I think it could be a bit simpler. I'm a
>> bit unsure
>> why it's coupled to the state and build results at all? Do we need
>> to track
>> these for historical purposes?
>>
>> I think at the moment we already have the error state, which AFAICT
>> are
>> always the result of configuration or transient errors. Perhaps we
>> could
>> replace that with this?
>>
>> The types of things I want to see it achieve are:
>> - same notification mechanism as the rest, but ability to separate
>> handling
>> (which we have with error types already)
>> - if it is corrected, it is as if it never happened - ie, no build
>> result,
>> no notification if it wouldn't have if it hadn't have happened (eg
>> SUCCESS
>> -> SVN FAIL -> SUCCESS should just report the SVN failure needs
>> fixing)
>> - make it possible for Continuum to know it needs to try something
>> again.
>>
>> I hope this makes sense... basically I think we should separate the
>> configuration/pre-build from the actual build.
>>
>> I'm still not sure if POM errors are really transient :)
>>
>> Thanks,
>> Brett
>>
>>
>> On 30/07/2008, at 12:06 PM, Marica Tan wrote:
>>
>> Hi All,
>>>
>>> I would like to work on the transient state.
>>>
>>> Here's what I'm proposing to do:
>>>
>>> 1. Add two new states: SVN_FAILURE and BAD_POM
>>> * thought of adding just one state: TRANSIENT_ERROR but it's not
>>> descriptive
>>>
>>> 2. When an error occur due to svn failure or bad pom configuration
>>> then
>>> a. create a build result and set the state to #1
>>> b. retain the old state and latestBuildId of the project ( before
>>> building / updating )
>>>
>>> 3. Add a new status icon for transient errors. ( No idea yet how
>>> it will
>>> look like. Any suggestions? )
>>>
>>> 4. In the ProjectGroupAction#summary class:
>>> a. check if there is a build result having SVN_FAILURE or BAD_POM
>>> state
>>> b. if exists, put it in the session for 5 mins and delete the build
>>> result from the database.
>>> c. if not, check if it's still in the session
>>> d. set project state = build result state
>>> e. display the state and associated error message
>>>
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Marica
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
Hi Brett
Do I still need to add new status icon for transient errors?
Thanks,
Marica
On Wed, Jul 30, 2008 at 2:58 PM, Brett Porter <br...@apache.org> wrote:
> Hi Marica!
>
> I like the idea, though I think it could be a bit simpler. I'm a bit unsure
> why it's coupled to the state and build results at all? Do we need to track
> these for historical purposes?
>
> I think at the moment we already have the error state, which AFAICT are
> always the result of configuration or transient errors. Perhaps we could
> replace that with this?
>
> The types of things I want to see it achieve are:
> - same notification mechanism as the rest, but ability to separate handling
> (which we have with error types already)
> - if it is corrected, it is as if it never happened - ie, no build result,
> no notification if it wouldn't have if it hadn't have happened (eg SUCCESS
> -> SVN FAIL -> SUCCESS should just report the SVN failure needs fixing)
> - make it possible for Continuum to know it needs to try something again.
>
> I hope this makes sense... basically I think we should separate the
> configuration/pre-build from the actual build.
>
> I'm still not sure if POM errors are really transient :)
>
> Thanks,
> Brett
>
>
> On 30/07/2008, at 12:06 PM, Marica Tan wrote:
>
> Hi All,
>>
>> I would like to work on the transient state.
>>
>> Here's what I'm proposing to do:
>>
>> 1. Add two new states: SVN_FAILURE and BAD_POM
>> * thought of adding just one state: TRANSIENT_ERROR but it's not
>> descriptive
>>
>> 2. When an error occur due to svn failure or bad pom configuration then
>> a. create a build result and set the state to #1
>> b. retain the old state and latestBuildId of the project ( before
>> building / updating )
>>
>> 3. Add a new status icon for transient errors. ( No idea yet how it will
>> look like. Any suggestions? )
>>
>> 4. In the ProjectGroupAction#summary class:
>> a. check if there is a build result having SVN_FAILURE or BAD_POM state
>> b. if exists, put it in the session for 5 mins and delete the build
>> result from the database.
>> c. if not, check if it's still in the session
>> d. set project state = build result state
>> e. display the state and associated error message
>>
>>
>> WDYT?
>>
>> Thanks,
>> Marica
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
Hi Marica!
I like the idea, though I think it could be a bit simpler. I'm a bit
unsure why it's coupled to the state and build results at all? Do we
need to track these for historical purposes?
I think at the moment we already have the error state, which AFAICT
are always the result of configuration or transient errors. Perhaps we
could replace that with this?
The types of things I want to see it achieve are:
- same notification mechanism as the rest, but ability to separate
handling (which we have with error types already)
- if it is corrected, it is as if it never happened - ie, no build
result, no notification if it wouldn't have if it hadn't have happened
(eg SUCCESS -> SVN FAIL -> SUCCESS should just report the SVN failure
needs fixing)
- make it possible for Continuum to know it needs to try something
again.
I hope this makes sense... basically I think we should separate the
configuration/pre-build from the actual build.
I'm still not sure if POM errors are really transient :)
Thanks,
Brett
On 30/07/2008, at 12:06 PM, Marica Tan wrote:
> Hi All,
>
> I would like to work on the transient state.
>
> Here's what I'm proposing to do:
>
> 1. Add two new states: SVN_FAILURE and BAD_POM
> * thought of adding just one state: TRANSIENT_ERROR but it's not
> descriptive
>
> 2. When an error occur due to svn failure or bad pom configuration
> then
> a. create a build result and set the state to #1
> b. retain the old state and latestBuildId of the project ( before
> building / updating )
>
> 3. Add a new status icon for transient errors. ( No idea yet how it
> will
> look like. Any suggestions? )
>
> 4. In the ProjectGroupAction#summary class:
> a. check if there is a build result having SVN_FAILURE or BAD_POM
> state
> b. if exists, put it in the session for 5 mins and delete the build
> result from the database.
> c. if not, check if it's still in the session
> d. set project state = build result state
> e. display the state and associated error message
>
>
> WDYT?
>
> Thanks,
> Marica
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/