Merging transient-state branch to trunk

[Marica Tan]

Hi,

Here's what I've done so far:

1. Separate prepare build from actual build
    - introduce PrepareBuildProjectsTask and
PrepareBuildProjectsTaskExecutor

2. Model change
    - added ProjectScmRoot ( which is used when updating ). Fields
(scmRootAddress, error, state, oldstate, projectGroup)
    - added scmRootAddress to Project which is the scmUrl of the root
project it belongs to.
    - added scmResult to Project. ( the scmResult in the BuildResult object
will no longer be used )

3. Group level updates
    - update all projects first before building them one by one.

4. Prepare build
    - state goes to the ProjectScmRoot; either updated (success) or error
only.
    - sets scmResult of project

5. Building
    - checks if ProjectScmRoot of the project is in successful state,
otherwise, do not build
    - no more scmResult in the build result of a project (it's still there
but no longer being used)

6. Cancelled build
    - no build result
    - project's state is set to it's previous state

7. UI
    - added ProjectScmRoot information
    - status icons: check for successful state, cross for error state
    - viewing of result: no result for successful state; click the
cross('x') icon to view the error.

8. Notification Mail    - configurable notification when scm failed.


Comments, suggestions and/or violent reactions are welcome :)


Thanks,
--
Marica

[Emmanuel Venisse-2]

On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <ctan@...> wrote:

> Hi,
>
> Here's what I've done so far:
>
> 1. Separate prepare build from actual build
>    - introduce PrepareBuildProjectsTask and
> PrepareBuildProjectsTaskExecutor
>
> 2. Model change
>    - added ProjectScmRoot ( which is used when updating ). Fields
> (scmRootAddress, error, state, oldstate, projectGroup)

What is it?

>
>    - added scmRootAddress to Project which is the scmUrl of the root
> project it belongs to.


Why a new field? it can be calculated from the scm url.

>
>    - added scmResult to Project. ( the scmResult in the BuildResult object
> will no longer be used )


Why? Will we continue to have the scm result in the build result page?


>
> 3. Group level updates
>    - update all projects first before building them one by one.


Is it an update of all projects in Continuum or all projects in a group?

>
>
> 4. Prepare build
>    - state goes to the ProjectScmRoot; either updated (success) or error
> only.
>    - sets scmResult of project
>
> 5. Building
>    - checks if ProjectScmRoot of the project is in successful state,
> otherwise, do not build
>    - no more scmResult in the build result of a project (it's still there
> but no longer being used)
>
> 6. Cancelled build
>    - no build result
>    - project's state is set to it's previous state
>
> 7. UI
>    - added ProjectScmRoot information
>    - status icons: check for successful state, cross for error state
>    - viewing of result: no result for successful state; click the
> cross('x') icon to view the error.
>
> 8. Notification Mail    - configurable notification when scm failed.
>
>
> Comments, suggestions and/or violent reactions are welcome :)

>
>
> Thanks,
> --
> Marica
>

[Marica Tan]

On Mon, Oct 20, 2008 at 8:50 PM, Emmanuel Venisse <
emmanuel.venisse@...> wrote:

> On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <ctan@...> wrote:
>
> > Hi,
> >
> > Here's what I've done so far:
> >
> > 1. Separate prepare build from actual build
> >    - introduce PrepareBuildProjectsTask and
> > PrepareBuildProjectsTaskExecutor
> >
> > 2. Model change
> >    - added ProjectScmRoot ( which is used when updating ). Fields
> > (scmRootAddress, error, state, oldstate, projectGroup)
>
>
> What is it?
>

This is a new table with the list of scm root address per project group
having a state, error, and oldstate on each.


> >
> >    - added scmRootAddress to Project which is the scmUrl of the root
> > project it belongs to.
>
>
> Why a new field? it can be calculated from the scm url.
>

When calculating for the scm root address, all I did was get the substring
of scm url that are common to the projects in the group (which now that I
think of it, seems wrong). Is there any other way how to do this? I'm not
sure how to calculate the scm root address from the scm url.


> >
> >    - added scmResult to Project. ( the scmResult in the BuildResult
> object
> > will no longer be used )
>
>
> Why? Will we continue to have the scm result in the build result page?
>
> No. I'll remove scmResult from BuildResult object.


>
> >
> > 3. Group level updates
> >    - update all projects first before building them one by one.
>
>
> Is it an update of all projects in Continuum or all projects in a group?
>
>
Update all projects with the same ProjectScmRoot in a group.

>
> >
> >
> > 4. Prepare build
> >    - state goes to the ProjectScmRoot; either updated (success) or error
> > only.
> >    - sets scmResult of project
> >
> > 5. Building
> >    - checks if ProjectScmRoot of the project is in successful state,
> > otherwise, do not build
> >    - no more scmResult in the build result of a project (it's still there
> > but no longer being used)
> >
> > 6. Cancelled build
> >    - no build result
> >    - project's state is set to it's previous state
> >
> > 7. UI
> >    - added ProjectScmRoot information
> >    - status icons: check for successful state, cross for error state
> >    - viewing of result: no result for successful state; click the
> > cross('x') icon to view the error.
> >
> > 8. Notification Mail    - configurable notification when scm failed.
> >
> >
> > Comments, suggestions and/or violent reactions are welcome :)
>
>
> >
> >
> > Thanks,
> > --
> > Marica
> >
>

[Emmanuel Venisse-2]

On Tue, Oct 21, 2008 at 4:33 AM, Marica Tan <ctan@...> wrote:

> On Mon, Oct 20, 2008 at 8:50 PM, Emmanuel Venisse <
> emmanuel.venisse@...> wrote:
>
> > On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <ctan@...> wrote:
> >
> > > Hi,
> > >
> > > Here's what I've done so far:
> > >
> > > 1. Separate prepare build from actual build
> > >    - introduce PrepareBuildProjectsTask and
> > > PrepareBuildProjectsTaskExecutor
> > >
> > > 2. Model change
> > >    - added ProjectScmRoot ( which is used when updating ). Fields
> > > (scmRootAddress, error, state, oldstate, projectGroup)
> >
> >
> > What is it?
> >
>
> This is a new table with the list of scm root address per project group
> having a state, error, and oldstate on each.
>
>
> > >
> > >    - added scmRootAddress to Project which is the scmUrl of the root
> > > project it belongs to.
> >
> >
> > Why a new field? it can be calculated from the scm url.
> >
>
> When calculating for the scm root address, all I did was get the substring
> of scm url that are common to the projects in the group (which now that I
> think of it, seems wrong). Is there any other way how to do this? I'm not
> sure how to calculate the scm root address from the scm url.

It should be ok in the majority of cases.
It can be wrong if a parent pom reference some submodules in an other SCM
repository. For example:

project A in http://host/repo1/trunk/A
project B in http://host/repo2/trunk/B

repo1 and repo2 are two svn instances and the common part (http://host)
isn't a svn directory. If a project use that, I think it's a very bad
practice and we can't know that repos are two instances.

>
>
> > >
> > >    - added scmResult to Project. ( the scmResult in the BuildResult
> > object
> > > will no longer be used )
> >
> >
> > Why? Will we continue to have the scm result in the build result page?
> >
> > No. I'll remove scmResult from BuildResult object.

hmm. I think it is important to know all changes done since latest build and
some Continuum instances send notifications only on latest committers.

>
>
>
> >
> > >
> > > 3. Group level updates
> > >    - update all projects first before building them one by one.
> >
> >
> > Is it an update of all projects in Continuum or all projects in a group?
> >
> >
> Update all projects with the same ProjectScmRoot in a group.

Good.
In the next versions, I'd like to remove checkout into the "project id"
directory, so it would be possible to run only one checkout for a group if
projects use the standard layout. For example, if you want to add Continuum
project into Continuum, you checkout only the trunk in "checkoutdir" and
sub-modules will be a sub directory of "checkoutdir"

>
>
> >
> > >
> > >
> > > 4. Prepare build
> > >    - state goes to the ProjectScmRoot; either updated (success) or
> error
> > > only.
> > >    - sets scmResult of project
> > >
> > > 5. Building
> > >    - checks if ProjectScmRoot of the project is in successful state,
> > > otherwise, do not build
> > >    - no more scmResult in the build result of a project (it's still
> there
> > > but no longer being used)
> > >
> > > 6. Cancelled build
> > >    - no build result
> > >    - project's state is set to it's previous state
> > >
> > > 7. UI
> > >    - added ProjectScmRoot information
> > >    - status icons: check for successful state, cross for error state
> > >    - viewing of result: no result for successful state; click the
> > > cross('x') icon to view the error.
> > >
> > > 8. Notification Mail    - configurable notification when scm failed.
> > >
> > >
> > > Comments, suggestions and/or violent reactions are welcome :)
> >
> >
> > >
> > >
> > > Thanks,
> > > --
> > > Marica
> > >
> >
>

[Marica Tan]

On Wed, Oct 22, 2008 at 4:39 PM, Emmanuel Venisse <
emmanuel.venisse@...> wrote:

> On Tue, Oct 21, 2008 at 4:33 AM, Marica Tan <ctan@...> wrote:
>
> > On Mon, Oct 20, 2008 at 8:50 PM, Emmanuel Venisse <
> > emmanuel.venisse@...> wrote:
> >
> > > On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <ctan@...> wrote:
> > >
> > > > Hi,
> > > >
> > > > Here's what I've done so far:
> > > >
> > > > 1. Separate prepare build from actual build
> > > >    - introduce PrepareBuildProjectsTask and
> > > > PrepareBuildProjectsTaskExecutor
> > > >
> > > > 2. Model change
> > > >    - added ProjectScmRoot ( which is used when updating ). Fields
> > > > (scmRootAddress, error, state, oldstate, projectGroup)
> > >
> > >
> > > What is it?
> > >
> >
> > This is a new table with the list of scm root address per project group
> > having a state, error, and oldstate on each.
> >
> >
> > > >
> > > >    - added scmRootAddress to Project which is the scmUrl of the root
> > > > project it belongs to.
> > >
> > >
> > > Why a new field? it can be calculated from the scm url.
> > >
> >
> > When calculating for the scm root address, all I did was get the
> substring
> > of scm url that are common to the projects in the group (which now that I
> > think of it, seems wrong). Is there any other way how to do this? I'm not
> > sure how to calculate the scm root address from the scm url.
>
>
> It should be ok in the majority of cases.
> It can be wrong if a parent pom reference some submodules in an other SCM
> repository. For example:
>
> project A in http://host/repo1/trunk/A
> project B in http://host/repo2/trunk/B
>
> repo1 and repo2 are two svn instances and the common part (http://host)
> isn't a svn directory. If a project use that, I think it's a very bad
> practice and we can't know that repos are two instances.
>
> >
> >
> > > >
> > > >    - added scmResult to Project. ( the scmResult in the BuildResult
> > > object
> > > > will no longer be used )
> > >
> > >
> > > Why? Will we continue to have the scm result in the build result page?
> > >
> > > No. I'll remove scmResult from BuildResult object.
>
>
> hmm. I think it is important to know all changes done since latest build
> and
> some Continuum instances send notifications only on latest committers.
>
> I added a new method called getChangesSinceLastUpdate, which will get all

changes in the scm result of a project.

> >
> >
> >
> > >
> > > >
> > > > 3. Group level updates
> > > >    - update all projects first before building them one by one.
> > >
> > >
> > > Is it an update of all projects in Continuum or all projects in a
> group?
> > >
> > >
> > Update all projects with the same ProjectScmRoot in a group.
>
>
> Good.
> In the next versions, I'd like to remove checkout into the "project id"
> directory, so it would be possible to run only one checkout for a group if
> projects use the standard layout. For example, if you want to add Continuum
> project into Continuum, you checkout only the trunk in "checkoutdir" and
> sub-modules will be a sub directory of "checkoutdir"
>
> >
> >
> > >
> > > >
> > > >
> > > > 4. Prepare build
> > > >    - state goes to the ProjectScmRoot; either updated (success) or
> > error
> > > > only.
> > > >    - sets scmResult of project
> > > >
> > > > 5. Building
> > > >    - checks if ProjectScmRoot of the project is in successful state,
> > > > otherwise, do not build
> > > >    - no more scmResult in the build result of a project (it's still
> > there
> > > > but no longer being used)
> > > >
> > > > 6. Cancelled build
> > > >    - no build result
> > > >    - project's state is set to it's previous state
> > > >
> > > > 7. UI
> > > >    - added ProjectScmRoot information
> > > >    - status icons: check for successful state, cross for error state
> > > >    - viewing of result: no result for successful state; click the
> > > > cross('x') icon to view the error.
> > > >
> > > > 8. Notification Mail    - configurable notification when scm failed.
> > > >
> > > >
> > > > Comments, suggestions and/or violent reactions are welcome :)
> > >
> > >
> > > >
> > > >
> > > > Thanks,
> > > > --
> > > > Marica
> > > >
> > >
> >
>

Is it alright to merge it to trunk?

--
Maria Catherine Tan
Software Engineer | Exist Global | [phone] loc 301 | skype: marica_tan
| www.exist.com | Innovation Delivered

[Wendy Smoak-3]

On Mon, Oct 27, 2008 at 12:01 AM, Marica Tan <ctan@...> wrote:

> Is it alright to merge it to trunk?

Hi Marica.  I think this has been merged already, but I'm trying to
link it up to a JIRA issue.  Was this all for CONTINUUM-1864 or did it
also cover CONTINUUM-1829?

CONTINUUM-1864   Transient State
 CONTINUUM-1829   separate transient errors from build failures in
notification and display

Thanks,
--
Wendy

[Marica Tan]

It also covers CONTINUUM-1829. Already closed the issues.
Thanks,
--
Marica

On Wed, Nov 5, 2008 at 12:55 AM, Wendy Smoak <wsmoak@...> wrote:

> On Mon, Oct 27, 2008 at 12:01 AM, Marica Tan <ctan@...> wrote:
>
> > Is it alright to merge it to trunk?
>
> Hi Marica.  I think this has been merged already, but I'm trying to
> link it up to a JIRA issue.  Was this all for CONTINUUM-1864 or did it
> also cover CONTINUUM-1829?
>
> CONTINUUM-1864           Transient State
>  CONTINUUM-1829          separate transient errors from build failures in
> notification and display
>
> Thanks,
> --
> Wendy
>