Hello,
we are about to replace the “java build” parts of our proprietary build tool with gradle.
Our own build tool is typically executed within a docker container (that contains the JDK to use, and a lot of stuff for the non-java build items). Some of our users do build locally (also using docker), and our jenkins based CI build also relies on the build running inside a docker container.
In order to enable a smooth introduction of gradle … the current build tool will just call gradle for the java build artefacts in the future. Thus our gradle build will run inside a docker container, too.
Now I am trying to understand how to the setup for our new gradle build. Thing is: currently, our CI runs three build jobs PER patch set, basically in parallel (on the same worker), as our product is delivered in 3 different flavours.
So, if we want a ROBUST build, we better: separate all output paths: although those 3 parallel build jobs look at the same source folders, all things build by them go into different directories. The only thing that they share would be the GRADLE_USER_HOME. First question: is that a reasonable setup? Or am I overlooking something here?
Second question: if we think about speeding things, is enabling the build cache a good idea? Or should that really be avoided, when you have multiple different gradle daemon instances writing to it “in parallel”?
Talking about gradle daemons: by default, our build is setup to use gradle daemon. Of course, that means in a docker environment: new docker image starts, gradle daemon needs to be started, gradle runs, docker image is pulled down … so we have that overhead of starting the daemon. Thus, third question: what are the pros/cons for using the daemon in this setup? Do we actually still gain “something” from using it?
Thanks for your thoughts and ideas!