You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Christian Gruber (JIRA)" <ji...@codehaus.org> on 2006/05/08 15:03:41 UTC

[jira] Created: (CONTINUUM-685) Make builds optionally build even when there are no changes

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


[jira] Commented: (CONTINUUM-685) Make builds optionally build even when there are no changes

Posted by "Christian Gruber (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/CONTINUUM-685?page=comments#action_64940 ] 

Christian Gruber commented on CONTINUUM-685:
--------------------------------------------

I linked this to CONTINUUM-686 (separate workspaces per build per project) because 686 is a possible solution for this issue (#2 above).  However, I still believe that even if 686 were implemented, the approach #1 (implement a boolean to ignore change when deciding whether or not to build) should still be implemented, as there are times when you would want building irrespective of change, even in the workspace of the given project.

> 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


[jira] Closed: (CONTINUUM-685) Make builds optionally build even when there are no changes

Posted by "Christian Gruber (JIRA)" <ji...@codehaus.org>.
     [ 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