-
Improvement
-
Resolution: Won't Fix
-
Major
-
None
-
Platform: All, OS: All
(pasted from message
http://www.nabble.com/Problem-with-incremental-builds-td24799079.html )
We're making use of the new incremental build feature, and I've noticed a problem.
Let's say I have two modules, "library" and "app", with "app" depending on
"library". If a commit fails a unit test in "library", Hudson correctly flags
the build. However, if a subsequent commit occurs on "app" (and "app" only),
Hudson will only execute the build of "app", and despite no one having committed
code to fix the unit test, Hudson reports this subsequent build as "passed".
This is because Hudson only built "app", and did not run library's unit tests.
In my opinion, if a previous build has failed, Hudson should keep using this
build's maven's "pl" argument, appending to it as necessary as more commits are
made. So, in my example, the first build would be invoked "mvn -pl library"
(since that's the module that has changed). The second build would be invoked
"-ol library, app", which is "pl of last build + new changes.
- is duplicated by
-
JENKINS-4243 invalid status when maven incremental build is used
-
- Closed
-
- is related to
-
JENKINS-5121 Deploy all built modules on success, including from previous failed builds
-
- Resolved
-
> so why run the build/tests again?
So Hudson can accurately report that the build is still failing.
I suppose you could simply assume that, if no commits occurred in the failing
module, subsequent builds are still unstable/failed. This would cut-down on the
build time. However, in most cases, I'd expect the optimization gained would be
negligible, and it seems more prudent just to endure the extra build duration.
This is an area where I think it would be wise to side-step any logic
determining which modules should be built. Brute-force in the name of caution.
Whatever the resolution, having a CI Engine report a pass when you're unable to
checkout and compile should be regarded as an egregious error. At the very
least, I think providing a warning about the use of this feature is necessary.