Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Won't Fix
-
None
-
Platform: All, OS: All
Description
(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.
Attachments
Issue Links
- is duplicated by
-
JENKINS-4243 invalid status when maven incremental build is used
-
- Closed
-
- is related to
-
-
- Resolved
-
Activity
Code changed in hudson
User: : abayer
Path:
trunk/hudson/main/core/src/main/java/hudson/model/Run.java
trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
trunk/hudson/main/test/src/test/java/hudson/maven/MavenMultiModuleTest.java
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=20953
Log:
[FIXED JENKINS-4152] Maven incremental build now will rebuild modules which were failed/unstable in previous build, even if there were no changes for those modules in this build.
wouter wendelen
added a comment - i don't understand why you not choose option #3 as a solution.
We currently have a complete build cycle of 4 hours. Whenever a certain module has failing tests and that module is a dependency of all other modules, everyting get's rebuilded on every checkin.
That is just not correct.
From my point of view, failed modules that fail because of network stuff or something else should be re-triggered by hand!
Any option to change this behaviour again?
wouter wendelen
added a comment - i don't understand why you not choose option #3 as a solution.
We currently have a complete build cycle of 4 hours. Whenever a certain module has failing tests and that module is a dependency of all other modules, everyting get's rebuilded on every checkin.
That is just not correct.
From my point of view, failed modules that fail because of network stuff or something else should be re-triggered by hand!
Any option to change this behaviour again? 
Tim Drury
added a comment - I see this behavior happening in Jenkins 1.596.1.
A job is configured for incremental build.
Module A fails due to a broken unit test.
A change to module B is made.
The next build builds only module B so the build goes green even though module A's unit test is still broken.
Unstable and failed modules should be included in the next incremental build (and subsequent builds until the module is stable).
Tim Drury
added a comment - I see this behavior happening in Jenkins 1.596.1.
A job is configured for incremental build.
Module A fails due to a broken unit test.
A change to module B is made.
The next build builds only module B so the build goes green even though module A's unit test is still broken.
Unstable and failed modules should be included in the next incremental build (and subsequent builds until the module is stable). The Maven plugin is kinda awful, so I'd generally advise not to use it, and definitely don't use the incremental build option. =)
Ok, this definitely won't make it in until 1.322 at the earliest - I've got a
bunch of actual paid work to do, and I'm having trouble getting my test
SCM-with-changelog working for the ITs for this feature. But I'll keep plugging
away.