Sandboxed Maven builds on Jenkins

Question

I am trying to find a solution for the following puzzle. I have java projects, managed by maven, which needs some native dependencies to work (run unit and integration tests). Those are provided in form of deb packages, which needs to be installed prior to running a build.

I use Jenkins for CI. Native dependencies can not be installed on Jenkins nodes, because of conflicts with other builds and they can change often. What I do now is not to create a Jenkins job type 'maven', but 'freestyle' and use a pbuilder to create an clean sandbox, install all that is necessary and invoke maven build.

This is working great, but I am loosing Jenkins maven goodies like automatic upstream projects, trigger build when dependency change, etc. Jenkins simply does not know that maven is there.

Finally, my question. Is there a way how to achieve both, isolate build so installed libraries does not affect other builds and leverage Jenkins's 'magic' applied to maven builds and their dependencies?

Answer 1

You could split your build in three jobs, which trigger the next one.

1. Create needed environment
2. Run maven job
3. Clean Up

Answer 2

The problem can be solved by using distributed Jenkins builds. Slave agents can be configured to provision clean environment (eg via VMs, docker,...) for each build and tear it down after build is done. This way Jenkins job can be of Maven type and any changes done by pre-build step will not affect others.

More information can be found here .

Answer 3

Consider docker. There you can run processes in isolated environments just as you want. Docker works in a way that it easily communicates with Jenkins.

As a benefit you can also use that docker container to run local builds in the same environment as they run in Jenkins.

Answer 4

Even a Freestyle job has "Invoke top-level Maven targets". You could use that to get "maven goodies" while also having ability to run other build steps.

There is an option to "use private Maven repository" which will make sure it will use the .m2/repository folder location relative to the workspace. If you need to separate into multiple jobs, you can use "Custom/shared workspace" between those jobs.

Even in Maven-style job, there is an option to use private repository, so that one job does not affect another.