-
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
-
[JENKINS-4152] Incremental builds should include previous builds' modules if previous build failed
Link |
New:
This issue is duplicated by |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Taking issue - still not entirely sure what the best resolution would be,
though. While I definitely see your point, I don't know if we really want to
keep building failed/unstable modules when nothing has changed in them since the
previous build. The point of the incremental build is to only build those
modules which have changed since the previous build - if module A has failed
tests in build 1 but there are no changes in it for build 2, we already know
what the result will be, so why run the build/tests again? It might make more
sense to clarify the result of build 2 in that situation - if a module is
skipped in a given build, reuse the result of its last build. I'll look into
this more, but probably won't get much (if anything) done before next week.