[ http://jira.codehaus.org/browse/CONTINUUM-685?page=all ]
     
Christian Gruber closed CONTINUUM-685:
--------------------------------------

    Resolution: Duplicate

> Make builds optionally build even when there are no changes
> -----------------------------------------------------------
>
>          Key: CONTINUUM-685
>          URL: http://jira.codehaus.org/browse/CONTINUUM-685
>      Project: Continuum
>         Type: Improvement

>   Components: Web interface, Core system
>     Versions: 1.0.3
>     Reporter: Christian Gruber
>     Priority: Minor

>
>
> This feature would be implemented in the UI as a simple check-box on each 
> build defintion, perhaps called "force builds with no changes".
> This would allow a given build to execute even if there are no changes, which 
> can be useful for daily builds attached to a parent (nested) project. 
> Scenario 1:
> The last change would have been at, say, 7:00pm the night before, but a daily 
> build still needs to be pushed and deployed.  The continuous integration 
> builds only go to the install goal, but policy puts a snapshot build on the 
> server every night.  However, currently, when the build on a daily schedule 
> executes, it checks for changes, and then aborts due to lack of change.
> Scenario 2:
> Similar to a daily build, but where site and site:deploy is not part of a 
> shorter-cycle of builds, so that the more frequent builds are not weighed 
> down by the time it takes to do a site build as well.  So when continuum goes 
> to execute a separate build target that was for site and site:deploy, on a 
> nightly or weekly schedule - the continuous integration build (on a five 
> minute loop) has succeeded, and therefore continuum thinks there are no 
> changes and bails.
> Possible implementation approaches.
> Simple addition to the build definition of a single boolean value, which is 
> "or"ed with the "did change" test.
> Another approach is to have each build definition, per project have its own 
> checked out version of the repository.  This way, if one build on one 
> schedule succeeds, it will not affect any other build definition's workspace 
> on that same project.  This would take up more space, but would allow for 
> cleaner separation of builds for different purposes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to