[ 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
