Ability to process scheduled builds the same as forced builds.

CONTINUUM-686 (seperate workspaces per build per project) relates to this, as it is one possible implementation strategy, though it's really its own thing as well, with other benefits. Having said that, implementing a simple boolean check for "force builds even with no changes" would resolve this issue more immediately and should be done regardless of 686

Having an ability to always execute a scheduled build is very useful, regardless of whether or not there were any code changes checked in.
This is a great way to uncover race conditions - the more often the tests run, the safer you feel. Isn't that the whole idea of unit testing? the hourly/nightly builds are always running and always testing, even if you are out on vacation.
So I strongly believe that being able to always have the build run even if there were no changes is a core part of Continuum functionality

The priority of this issue shouldn't be "minor" as it is an essential feature of a Continuous Integration Systems. I'd like to fix this bug and would appreciate it if anyone give me a hint as to what components I need to look at to resolve the bug.

Thanks.

We could really use this feature right now (need it yesterday)
Because we only do a site build/publish build once a day, it must run even if one of the hourly builds have already updated the source.

Currently we're forced to run the nightly build and deployment in a cron outside of Continuum.

+1

I would also love to have the ability to force the site build. In fact, it seems that most of us want this because we either run a different lifecycle (site build vs. software build) or let it run up to different phases (test vs. integration-test).

IMHO, it makes sense that Continuum would be able to understand that having a build that ran up to the test phase didn't include the integration-test phase; as a result, Continuum should be able to recognize that a midnight integration test still requires the build to run, even if the test build already ran and there were no changes in the repository.

The same applies for the difference between a site build and a software build. You would expect Continuum would be able to see the difference between the different lifecycles. Because of that, it should simply be running the nightly site build, even if the software build already completed successfully during the day.

+ 1

For us it would be already a great (really great) help just to have a checkbox "Force build" or "Build always" as an attribute of a build defintion. The priority minor does not correctly reflect our need for such a feature.

Have another argument for this ability:

with the one component per module style of Maven, modules that have been stable but have unstable dependent modules can get out of sync.

e.g. two source modules, one nobody spends time in and another that is being reworked all the time. Since the
"stable" module doesn't change, it will never be built and the changes that broken it from module 2 will not be detected.

For a fix:

• Dependency change checking.
• scheduled force build.

I don't care which way I have to do it, but some way would be helpful.

upping priority to major...

also, the build on dependency has been added to trunk so the modules in your example should be getting rebuilt now

Is this addressed by the "Always Build" checkbox on the build definition?

That makes the scheduled build always happen, regardless of whether there are any changes in scm.

If not, what behavior are you looking for? I'm confused by the use of 'default' 'forced' and 'scheduled' in the original description.