[
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:
{{{
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)
> Incrememntal 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
