Hi,
I noticed the following remark in the user guide (chapter 20) on the gradle daemon and continuous integration: ‘We don’t run CI builds with the daemon (i.e. a long running process) as the CI environment is optimized for consistency and reliability.’
Can you elaborate on that? Other than long running processes (in which the benefit of a fast startup time of gradle is minimal), can you mention other reasons?
With kind regards,
Joris
I’m not quite sure I understand the question, as the reason given is “consistency and reliability”, not “long-running process”. Anyway, to elaborate on that statement: On CI, stability trumps everything. A long-running process always bears risks such as memory leaks, even more so if it runs arbitrary code and plugins. Also, especially on Windows the Gradle daemon isn’t yet as stable as we would like it to be.
If your CI agents don’t run on Windows, it may be worth giving the daemon a shot. In particular because in recent Gradle versions, using the daemon results in performance improvements beyond startup time.
I’m usually using Gradle on Windows (locally, not on CI) and I haven’t seen any issue on Windows for a long time (maybe the last one I have seen was in 1.4) other than the known platform independent issues. So, to be fair, the daemon is rather stable. I still don’t use it on CI just to be sure.
That’s good to hear. We’ve been getting mixed feedback on this (for Windows), but often we don’t have hard data on which Gradle versions users are running.