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: Merging transient-state branch to trunk
Date Wed, 22 Oct 2008 08:39:03 GMT
On Tue, Oct 21, 2008 at 4:33 AM, Marica Tan <ctan@exist.com> wrote:

> On Mon, Oct 20, 2008 at 8:50 PM, Emmanuel Venisse <
> emmanuel.venisse@gmail.com> wrote:
>
> > On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <ctan@exist.com> 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
> > >
> >
>

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