Use of Gradle Daemon in ephemeral build containers

What’s the recommended practice for Gradle builds in ephemeral CI build containers: with or without starting the Gradle Daemon?
In the older documentation it was clearly stated one could disable Gradle Daemon for perhaps a slight performance increase.

If you run CI builds in ephemeral environments (such as containers) that do not reuse any processes, use of the Daemon will slightly decrease performance (due to caching additional information) for no benefit, and may be disabled.

But in the current documentation this piece of information is lacking…

Would appreciate if someone could clarify this point.


If you do one Gradle call, it doesn’t really make much difference.
Even when disabling the daemon, there is always a daemon used to be consistent, it is just not kept alive after the build finished. So whether Gradle shuts down the daemon or whether it is shut down due to the build container being shut down does not make too much of a difference.

If you do multiple Gradle calls, then definitely keep it enabled, as you otherwise need to start two daemons instead of reusing the daemon from the first call.

1 Like

I don’t quite understand this. When I run Gradle on CI, each build starts a daemon (taking ~ 1 minute), whereas when daemon is disabled, it seems to start the job instantly. It doesn’t seem Gradle has been optimised for ephemeral build environments as my daemons are never reused between builds on Azure (labelled as incompatible). This means my pipeline takes almost twice as long when using the daemon. Have the Gradle devs considered this case? Why is it recommended to use the daemon on CI? Thanks

1 Like

Starting a daemon can not really take a minute except maybe if you build on a phone.
And as I said, even “disabling” the daemon just disables reuse, so the daemon is quit at the end of the build.
If there is a significant difference (and one minute is quite significant) between starting with daemon enabled and disabled without anything else changed, I think it should be investigated why.
Maybe you can look at build --scans or use the gradle-profiler or compare debug logs or similar, and probably report an issue about it.