Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-4152

Incremental builds should include previous builds' modules if previous build failed

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Component/s: maven-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:
      Show 5 results

      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

            Activity

            Hide
            abayer Andrew Bayer added a comment -

            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.

            Show
            abayer Andrew Bayer added a comment - 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.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            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.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            Hide
            woutie 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?

            Show
            woutie 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?
            Hide
            timdrury 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).

            Show
            timdrury 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).
            Hide
            abayer Andrew Bayer added a comment -

            The Maven plugin is kinda awful, so I'd generally advise not to use it, and definitely don't use the incremental build option. =)

            Show
            abayer Andrew Bayer added a comment - The Maven plugin is kinda awful, so I'd generally advise not to use it, and definitely don't use the incremental build option. =)

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                hopfrog238 hopfrog238
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: