continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Dependency triggered builds
Date Fri, 15 Sep 2006 01:54:19 GMT

On 15/09/2006, at 12:34 AM, Emmanuel Venisse wrote:

> 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 started 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
> Emmanuel
> 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