Gradle daemons in demos and Buildbot builds?

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[taher]

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
<[hidden email]> 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
>

[Jacques Le Roux]

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
> <[hidden email]> 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
>>