Re: Gradle daemons in demos and Buildbot builds?
Thanks Taher,
That's maybe right indeed, I have no ways to check that without trying. So the
risk is not worth it, let's forget it and those Gradle messages.
And what about parallel ? It can be safely used now.
Locally you can add "org.gradle.parallel=true" in your gradle.properties (where
you have Gradle installed) that's what I use for a moment.
I removed it and tested using or not --parallel with "gradlew clean build" several time. It does not seems to have any influence on the performances
locally
I had a look at https://guides.gradle.org/performance/ and tried the --scan on
a build after a clean
I found some possible improvements:
adding "options.fork = true" in tasks.withType(JavaCompile) { w/ and w/o
--parallel
Did not note any noticeable performance improvement
Also tried
|tasks.withType(Test){reports.html.enabled =falsereports.junitXml.enabled
=false}|
I guess since we have only few tests it does not give any performance
improvement at the moment. Could be useful later...
So no need to change anything for OFBiz
Jacques
Le 25/12/2018 à 11:39, Taher Alkhateeb a écrit :
I recommend not to run the daemon in CI. It's not worth the
instability to gain a few seconds on each run.
On Mon, Dec 24, 2018 at 7:45 PM Jacques Le Roux
wrote:
Hi,
So far, from Gradle team recommendation, we were not using Gradle daemons in
demos and Buildbot builds.
In both, I recently noticed warnings like
To honour the JVM settings for this build a new JVM will be forked. Please
consider using the daemon:
https://docs.gradle.org/5.0/userguide/gradle_daemon.html. Daemon will be
stopped at the end of the build stopping after processing
There I can read:
/Continuous integration//
//Since Gradle 3.0, we enable Daemon by default and recommend using it for
both developers' machines and Continuous Integration servers. However,
if you suspect that Daemon makes your CI builds unstable, you can disable
it to use a fresh runtime for each build since the runtime is
//completely//isolated from any previous builds./
I think we can try it, what do you think?
Also, I'm using --/parallel /for quite a moment now. Since we switched to
Gradle 5 I no longer see warnings about that. Should we not use it in demos
and Buildbot builds and maybe enforce it generally?
Thank you for your opinions.
//
Jacques
Re: Gradle daemons in demos and Buildbot builds?
I recommend not to run the daemon in CI. It's not worth the instability to gain a few seconds on each run. On Mon, Dec 24, 2018 at 7:45 PM Jacques Le Roux wrote: > > Hi, > > So far, from Gradle team recommendation, we were not using Gradle daemons in > demos and Buildbot builds. > > In both, I recently noticed warnings like > > To honour the JVM settings for this build a new JVM will be forked. > Please consider using the daemon: > https://docs.gradle.org/5.0/userguide/gradle_daemon.html. Daemon will be > stopped at the end of the build stopping after processing > > There I can read: > > /Continuous integration// > //Since Gradle 3.0, we enable Daemon by default and recommend using it > for both developers' machines and Continuous Integration servers. However, > if you suspect that Daemon makes your CI builds unstable, you can disable > it to use a fresh runtime for each build since the runtime is > //completely//isolated from any previous builds./ > > I think we can try it, what do you think? > > Also, I'm using --/parallel /for quite a moment now. Since we switched to > Gradle 5 I no longer see warnings about that. Should we not use it in demos > and Buildbot builds and maybe enforce it generally? > > Thank you for your opinions. > // > > Jacques >
Re: Gradle daemons in demos and Buildbot builds?
Le 24/12/2018 à 17:43, Jacques Le Roux a écrit : Hi, So far, from Gradle team recommendation, we were not using Gradle daemons in demos and Buildbot builds. In both, I recently noticed warnings like To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/5.0/userguide/gradle_daemon.html. Daemon will be stopped at the end of the build stopping after processing There I can read: /Continuous integration// //Since Gradle 3.0, we enable Daemon by default and recommend using it for both developers' machines and Continuous Integration servers. However, if you suspect that Daemon makes your CI builds unstable, you can disable it to use a fresh runtime for each build since the runtime is //completely//isolated from any previous builds./ I think we can try it, what do you think? Also, I'm using --/parallel /for quite a moment now. Since we switched to Gradle 5 I no longer see warnings about that. Should we not use it in demos and Buildbot builds and maybe enforce it generally? Thank you for your opinions. // Jacques I think the limitations of the parallel option[1] should work for us, but please check by yourself in case I missed something [1] https://docs.gradle.org/current/userguide/multi_project_builds.html#sec:parallel_execution Jacques
