[ 
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

        

Reply via email to