[
https://issues.apache.org/jira/browse/LUCENE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17434347#comment-17434347
]
Uwe Schindler edited comment on LUCENE-10195 at 10/26/21, 1:09 PM:
-------------------------------------------------------------------
{quote}
I understand you're advocating for gradle cache and I think it's great but I
don't think it should be the
default setting - sorry, this is my honest opinion. Unless you have a bunch of
corporate CI servers it'll only pollute
your home with a gazillion of megabytes of data that will simply not be reused
much. And we do want folks
to run stuff in their own environments because this is a good regression test
(different VMs, operating systems).
If somebody wants a local cache, they can enable it but it shouldn't be forced
down their throats.
{quote}
I fully agree with this. PLEASE DO NOT ENABLE THE BUILD CACHE BY DEFAULT. As a
developer I want and expect to take the build longer if I run "gradlew clean".
I want "gradlew clean" to forget the build and then compile everything again
and especially, I want the build to rerun all checks and tests!!!!
As provider of the Lucene build servers, every run should do all build steps
again, because we want to test out JVM problems and this only works if the
gradle build forgets everything.
I just ping [~rcmuir], because he also has a strong opinion on that.
So in short. Some of the changes in the PR looks fine, but everything that
caches stuff on my local disk and serializes test results and checks thats
should be avoided sorry!
Thanks for including my opinion.
Uwe
P.S.: IMHO the Gradle build cache is a feature for streamlined projects with
zillions of build servers to spare CPU resources mabye in organizational
environments where the business logic is important. But For Lucene, if we have
a zillion of build servers we want all of them redundantly run tests to find
bugs in the JVMs. This is why we run the tests with different settings
(compressed ops on/off, different Garbage collectors). That's what Policeman's
Jenkins server is behind: Find bugs in Garbage collectors and different JVM
version by running the build suite and tests 24/7. Also [~mikemccand] does this
every night to monitor performance. Everything caching results would be a
desaster!
If the build cache helps local developers, ok -- but more important is to
configure Input/Outputs correctly. I have a local machine with one operating
system and dont need to cache results several days. It's only working myself.
was (Author: thetaphi):
{quote}
I understand you're advocating for gradle cache and I think it's great but I
don't think it should be the
default setting - sorry, this is my honest opinion. Unless you have a bunch of
corporate CI servers it'll only pollute
your home with a gazillion of megabytes of data that will simply not be reused
much. And we do want folks
to run stuff in their own environments because this is a good regression test
(different VMs, operating systems).
If somebody wants a local cache, they can enable it but it shouldn't be forced
down their throats.
{quote}
I fully agree with this. PLEASE DO NOT ENABLE THE BUILD CACHE BY DEFAULT. As a
developer I want and expect to take the build longer if I run "gradlew clean".
I want "gradlew clean" to forget the build and then compile everything again
and especially, I want the build to rerun all checks and tests!!!!
As provider of the Lucene build servers, every run should do all build steps
again, because we want to test out JVM problems and this only works if the
gradle build forgets everything.
I just ping [~rcmuir], because he also has a strong opinion on that.
So in short. Some of the changes in the PR looks fine, but everything that
caches stuff on my local disk and serializes test results and checks thats
should be avoided sorry!
Thanks for including my opinion.
Uwe
P.S.: IMHO the Gradle build cache is a feature for streamlined projects with
zillions of build servers to spare CPU resources mabye in organizational
environments where the business logic is important. But For Lucene, if we have
a zillion of build servers we want all of them redundantly run tests to find
bugs in the JVMs. This is why we run the tests with different settings
(compressed ops on/off, different Garbage collectors). That's what Policeman's
Jenkins server is behind: Find bugs in Garbage collectors and different JVM
version by running the build suite and tests 24/7. Also [~mikemccand] does this
every night to monitor performance. Everything caching results would be a
desaster!
> Gradle build speed improvement
> ------------------------------
>
> Key: LUCENE-10195
> URL: https://issues.apache.org/jira/browse/LUCENE-10195
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Jerome Prinet
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Increase Gradle build speed with help of Gradle built-in features, mostly
> cache and up-to-date checks
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
