Incremental build in Jenkins

Question

I am using Jenkins 1.462 and maven version is 3.0.4. At Jenkins I enabled check-box "Incremental build - only build changed modules"

I want to figure out 2 questions:

1. Whether incremental build is sufficient? Here How do I trigger a Jenkins build of a single module in a multi-module Maven build from Subversion? for example is stated that it doesn't work at 100% Here http://www.slideshare.net/andrewbayer/7-habits-of-highly-effective-jenkins-users at page 19 is stated that incremental builds are complementary to full builds, not replacements.

2. Whether Incremental build - only build changed modules is actually works as expected? What I mean by this? If I have modules A, B, X, C, D. X uses A and B, C use X, D use C and I make change in X module. Than I want to recompile modules X (itslef), C (that use X directly) and D (that is in transitive closure; D use C, that use C).

Note: this is the only change that I did in order to enable incremental build.

Solution

As stated by Maven documentation incremental builds are not very reliable at least until 3.0.4:

Currently (3.0.4) Apache Maven doesn't support incremental builds very well.

https://cwiki.apache.org/confluence/display/MAVEN/Incremental+Builds (first line)

Instead, I would strongly suggest using any of these two approaches for speeding up your build:

• Using parallel builds. In my experience in large projects this works great and can greatly reduce the build time with minimum (if any) risk. Just execute something like mvn -T 1.5C clean install https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3

• If your modules are independent you can rather move them to different projects and glue them together by using maven dependencies.

Comments

[marcv81]

Downvoted as the proposed solution creates very severe issues: using "mvn install" in Jenkins will create unexpected behaviours if you have more than 1 build machine or build more than 1 branch. Generally speaking a build should never rely on the state of the build machine, which is why "mvn install" is an incredibly dangerous idea. If you have interdependencies use a repository manager, and update the dependencies versions when required (without enabling "overwrite versions" otherwise you loose repeatability).

[Adrián Deccico]

hi marcv81, mvn install does not necessarily relies on the state of the build machine. If you are are using Maven to release then you should also use a central repo to push and pull your artifacts. In any case you can replace install for any other target if you wish, the question is about speeding up a build, not about dependency management for which Maven has several options.

[marcv81]

Hi Adrian, mvn install alters the state of the build machine by default as it installs artifacts in the local repository. This would influence the outcome of the next build which has a dependency on the current build. The question is about performance yet the answer breaks build repeatability hence my downvote/comment. I mentioned using an artifact repository; an additional good practice to implement this correctly is to spin up a new VM for each build. The poor man's version is to rm -rf ~/.m2/repository before every build.

[Adrián Deccico]

Hi marcv81, compiling also change the state of the local machine. Everything modify the current state of the local environment. Even a rogue test launched by Maven can prevent the next build to succeed. mvn install is just another legitimate command and you need to know why or when to use it and what the trade-offs are.

[marcv81]

Don't get me started on poorly written tests ;-)