[ https://issues.jenkins-ci.org/browse/JENKINS-13758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephan Pauxberger updated JENKINS-13758: ----------------------------------------- Description: 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) was: 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. > Incremental Builds: If a build is aborted right after a failed one, not all > necessary modules are build > ------------------------------------------------------------------------------------------------------- > > Key: JENKINS-13758 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13758 > Project: Jenkins > Issue Type: Bug > Components: maven > Environment: Jenkins 1.443, Linux, 64bit > Reporter: Stephan Pauxberger > > 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) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira