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
