On Tue, Oct 21, 2008 at 4:33 AM, Marica Tan <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 20, 2008 at 8:50 PM, Emmanuel Venisse < > [EMAIL PROTECTED]> wrote: > > > On Mon, Oct 20, 2008 at 4:47 AM, Marica Tan <[EMAIL PROTECTED]> 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 > > > > > >
