continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <>
Subject Re: Dependency triggered builds
Date Thu, 14 Sep 2006 14:34:40 GMT
Personally, I prefer the PULL method.
I think we need to have two type of analysis.
The first is for dependencies that have a corresponding project in continuum.
The second is for other dependencies that are available in the repo.

For the first one, we need the lastKnownBuildId or just check if the latest dependy build
is more 
recent than the latest project build.
For the second, we can check the timestampof the dependency or just check if the dependency
file is 
more recent than the latest project build.

I think we need to check if the parent pom is newer or not too.

For PULL(3), I think too that it will be for 1.2 because it require lot of work. Trygvis has
a branch with osworkflow but if I remember it correctly, he didn't like it and want to try
his own 
engine started in plexus-sandbox/plexus-components/plexus-spe


Kenney Westerhof a écrit :
> Hi,
> I wanted to propose some solutions for triggering builds if dependencies 
> are changed.
> (I mean: if project A depends on project B, and project B was 
> updated/rebuilt, then
> A should also be rebuilt to check for any api breaking changes etc.).
>> From the top of my head I can name 2 distinct approaches: push and pull.
> PUSH: When project B was succesfully built (no need to trigger other 
> builds for broken
>  builds - no new artifact is available),
>  Continuum will schedule forced builds for all projects that depend on 
> the current project.
> PULL (1): MavenTwoContinuumProjectBuilder does an SCM check to see if 
> there are any source changes.
>  Add another check here to see if any dependencies have newer build 
> Id's. This requires a 'lastKnownBuildId'
>  field to be added to the project<->project relation (Dependency).
> PULL (2):  Same thing, except we just check for the timestamp of 
> dependency builds. If they're newer than ours,
>  then run the build.
> PULL (3):
>  Either one of the above, but not in the project builder, but as a 
> task-entry-evaluator.
>  Also the 'SCM' up2date check would be moved to an evaluator class 
> (something like if ( `svn log CURRENT:HEAD | wc -l` > 0 ) {}: don't update
>  the checkout, just check if it would be changed).
>  If the first evaluator fails, the next one isn't called (I assume...). 
> This is an 'AND' operation.
>  We might also want to support an OR operation, (scmChanged || 
> depsChanged).
>  This is starting to look like a workflow. The advantage of this is that 
> we can break down all the operations
>  that are now hardcoded in the different build executors to separate 
> actions that we can chain together,
>  and add decision points.
>  We could use Werkflow/OSWorkflow or some other engine, or just plexus, 
> which already has a workflow engine (in the form of the taskQueue).
>  For instance (without TaskEntryEvaluators):
>     Each action defines it's outputs: yes/no/others as requirements.
>      The first action would be 'CheckDependenciesChangedAction'.
>     If this evaluates to 'yes', it schedules the 'yes' action, which would
>     be the BuildProjectTask.
>     When 'no', then schedule 'CheckSCMUpdatedAction'.
>     and so on and so forth.
> With TaskEntryEvaluators this could also be done, as long as each 
> evaluator can specify the next evaluator to run.
> But I think this is for 1.2; just wanted to bring it up for discussion.
> If there's no feedback on a preferred solution I'll go with either the 
> PUSH or PULL 1/2 solutions,
> whichever is easiest. I'll do some research on what's there yet to 
> support this.
> -- Kenney

View raw message