Seems like a nice performance improvement! Am I correct in understanding that the cache when merged would still be in your personal S3 bucket? If that is the case, I wonder if we can instead connect with INFRA to see about the possibility for ASF-managed storage.
-- Michael Mior [email protected] Le sam. 25 juil. 2020 à 11:31, Vladimir Sitnikov <[email protected]> a écrit : > > Hi, > > What do you think if we configure Gradle Remote Build Cache for Calcite? > (see https://guides.gradle.org/using-build-cache ) > > It could significantly improve PR and regular builds: 12min -> 9min (see > below). > > I'm inclined to polish the caching configuration and merge it provided > there are no objections within a week. > https://github.com/apache/calcite/pull/2081 > > --- > > It could cache the results of cacheable tasks across builds. For instance, > checkstyle/javadoc/javac results are perfectly cacheable. > Then, if we don't touch linq4j, Gradle could reuse checkstyle/javadoc/javac > results from a known good build. > The cache does account for Java version, classpath, and so on. > > I've configured a cache into my own S3 bucket. > The cache would be populated by GitHub Actions branch-based builds (PR > builds would be read-only) > > Recent macOS, JDK14 build took 12:24 > https://github.com/apache/calcite/runs/909244400?check_suite_focus=true > The one with build cache took 9:36 > https://github.com/apache/calcite/runs/909907954?check_suite_focus=true > > S3 cache 05:27 saved (05:27 saved on hits, 618ms wasted on misses), reads: > 162, hits: 142, elapsed: 11s, processed: 8 MiB > I'm not sure why estimated time saving says 5:27 while the actual duration > difference is 2:48, however, making PR builds faster is nice anyway. > > For some reason Javadoc tasks result in cache miss (see build scan > https://scans.gradle.com/s/b5ibehsnmyqxg/timeline?cacheableFilter=cacheable&hideTimeline&outcomeFilter=SUCCESS,FAILED&sort=longest > ), > so net saving could be more than listed above. > > Test execution is cached yet as there might be tests that depend on > databases that we can't predict and shouldn't cache. > It might be a good idea to make some of the tests cacheable. I believe it > should be OK to cache tests that depend on Calcite only. > > Vladimir
