I understand the Gradle daemon is still considered somewhat experimental, but I believe the plan is for it to be enabled by default at some point. If so, I would like to see a lot more documentation on how it behaves, especially in a CI use case with multiple users running multiple builds on the same box.
Here are a few questions I have so far: 1. Will it be recommended to use the daemon on a CI server? 2. Can a single daemon process be shared among builds? i.e. Can concurrent builds use the same daemon process? 3. Is the daemon Gradle-version agnostic, or does there need to be a daemon process per Gradle version? If so, does Gradle handle this automatically? 4. When a daemon process has an issue what happens? Do all subsequent builds fail until you do a --stop? Does it automatically kill and restart? Obviously you can’t account for everything, but are there any specific things that are handled or planned to be handled?
I’ve only done some minor testing on my local machine; I don’t know how much of this is obvious once you’ve used it for a while.
We are not quite sure, but leaning towards yes. It can shave minutes off some builds. 2. No, one build per process 3. The daemon is tied to the Gradle version, and this is handled transparently 4. The intent that if a daemon is compromised it will terminate. The only specific plans we have for this right now is to watch memory usage and preemptively terminate if memory is getting low.
As for 3. there will likely be some kind of coordination in the future so you can at least use a gradle command to see other daemons that are running from other versions. But in terms of normal operation, Gradle only can see daemons of its version.
Followup question on #2. If only one build can be running on a daemon process at a time, what happens when a second build executes that wants to use the daemon (same JDK and same version of Gradle). Does it get in line to use the daemon? Does it fail saying the daemon is in use? Does it spin up a new daemon process? Does it execute as a daemon-less build?
Right now, you are then going to have to sitting around idle afterwards. Eventually we’ll only keep one around for a long time, dropping the idle timeout on older processes. We’ll likely also let you specify how many long lived daemons you want to keep around. We might also put an upper bound on the number of daemons, not sure if this is that useful though.
So when we have this, if you launched 30 builds at once you’d end up with 60 JVM processes. Then at most say 5 minutes after the last build finishes you’d only have one still around. Make sense?