A build must always be executed when previous was in failure even if there are no changes in scm

If this means what I think it means, you're saying that a build should try again and again and again until it works. I disagree - this is a waste of machine resources and can result in mail-bombing of the notify list. (CruiseControl behaves like this and it's a pain in the neck!) Also, in the case of a clean rebuild, the artifacts that a developer would need to use to diagnose the failure would be repeatedly erased.

An elegant way to satisfy this would be to only send notifications if there are changes in build success (repeated failures would generate no additional notifications), or to just send a message saying that no more builds will happen until either an SCM change is noticed or someone forces a build (after they diagnose the problem and fix it).

-1 too.

Builds should only be happening on SCM change, or at a scheduled time (ie: a nightly clean build).

If a dependency of the the project is a continuum project and it change since last failure, then we'll execute a new build of the project even if there are no changes in scm.

I want to do that because a failure can be occurred because of a bad dependency.

I agree with all of you!

It should not build unconditionally if the last build was a failure, but if any "external resource" has changed, where the source code and a dependency are two examples of external resources. We should make a separate component in Continuum to run the preconditions for a build.

I firmly support this as a build definition option. I believe that it should be an option that it build in all cases of failure, though that wouldn't be how some of the commenters would choose to invoke it. It might be a waste of resources in many cases, but in several environments I have been forced to work in, the environment was flakey enough that when running the integration tests, they would often fail because a bridge was down, or a tunnel. The tests needed to keep trying until it was up again, and spam certain people until it worked.

This is a slightly different case from what Trygve proposes, because many of these external resources of which I speak are too hard to test... or to put it another way, the execution of these tests IS the proof of those resources, so they cannot be pre-evaluated by reasonable means. In this case, the whole is dependent on unknowables, and should therefore be retried until successful.

Again, I agree that this can be wasteful, and this should not be the only way to configure it. You should, I think, be able to configure it to fail once, try again if detectable upstream dependencies change, or try again until successful. I don't know of any other states for this option.

I originally agreed with the comments from Jamie Flournoy, Henri Yandell, Trygve Laugstol but after using it for a while I have changed my mind. The reason is that there are many things that can cause a build to fail including dependency issues, build order, environment (e.g. systems bounces the cvs server) etc. and in those cases you do not want to change the code in the module thats failing because its dependency is failing.

I've run into all of those mentioned in the last few weeks and it's a bit of a pain to have to go and "force" build the module.

The only way to be sure that a build reruns if it fails is to run it even if there are no changes. If you don't have this ability then you have to manually go an force a build when it not actualy required.

So IMO, Christian Gruber has the best idea – make it configurable.

One more comment in support of this.

I work in a place where the developers have some bad habits, particularly those not on my own team.
In the case of a failing build, i want the individual who committed the broken code to get spammed (not everyone, except maybe their lead) because I'm getting tired of people ignoring the failure notice (I often have to go track them down).

I think that is no excuse for poor practice/process but there are times when it can't be helped.

I think this behaviour needs to be configurable