This is related to JENKINS-5764.

We had the following scenario:

A->B->C (All Modules)
   X->Y

Now, we introduce a change in A which breaks C (changed an interface in our case). (#1)

Now, something completely different is changed in X, which additionally breaks Y (#2)

Since the last build failed, A,B,C are built as well. Before the build reaches C, it already fails due to failure of Y. In that moment, the developer realizes a mistake and aborts the build.

Now he fixes his error in X,Y and commits. (#3)

Incremental build only builds X,Y, i.e. the build succeeds. Expected would be to build A,B,C as well as X,Y.

The next time someone changes something in C (no code, in our case), the build suddenly fails (two days after the "bad commit"!) (#10)

Proposed solutions:

Easiest, but most expansive:

After an aborted build, always do a full build (not incremental)

Better solution:

For a new build:

• The list of modules to build includes all modules changed since last commit
• go back in history until (not including) the last successful build, for all builds that are NOT successful, include those run's changed modules as well
• if there are no successful builds in the build history, always do a full build.

That way, the problem above would not happen, because commit #3 would result in a previously affected modules since the last successful build to build rebuild as well (resulting in a breaking build for C).

Note that this bug should also affect a couple of other fixed bugs (like JENKINS-5121)