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

Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None
    • Jenkins 1.443, Linux, 64bit

      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)

          [JENKINS-13758] Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build

          Stephan Pauxberger created issue -
          Stephan Pauxberger made changes -
          Link New: This issue is related to JENKINS-5121 [ JENKINS-5121 ]
          Stephan Pauxberger made changes -
          Link New: This issue is related to JENKINS-5764 [ JENKINS-5764 ]
          Stephan Pauxberger made changes -
          Description Original: 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)
          		 New: This is related to JENKINS-5764.

          We had the following scenario:

          {code}
          A->B->C (All Modules)
             X->Y
          {code}

          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)
          Stephan Pauxberger made changes -
          Description Original: This is related to JENKINS-5764.

          We had the following scenario:

          {code}
          A->B->C (All Modules)
             X->Y
          {code}

          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)
          		 New: This is related to JENKINS-5764.

          We had the following scenario:

          {code}
          A->B->C (All Modules)
             X->Y
          {code}

          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)

          UPDATE: The "better solution" above is already implemented (except for this bug). I will look further into the code.
          Summary Original: Incrememntal Builds: If a build is aborted right after a failed one, not all necessary modules are build New: Incremental Builds: If a build is aborted right after a failed one, not all necessary modules are build
          Stephan Pauxberger made changes -
          Description Original: This is related to JENKINS-5764.

          We had the following scenario:

          {code}
          A->B->C (All Modules)
             X->Y
          {code}

          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)

          UPDATE: The "better solution" above is already implemented (except for this bug). I will look further into the code.
          		 New: This is related to JENKINS-5764.

          We had the following scenario:

          {code}
          A->B->C (All Modules)
             X->Y
          {code}

          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)
          Stephan Pauxberger made changes -
          Assignee New: kutzi [ kutzi ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 144225 ] New: JNJira + In-Review [ 176103 ]

            kutzi kutzi
            paux Stephan Pauxberger
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: