I've fixed javadoc by adding the task to the cache seed job (Javadoc is not built by default).
Now the cached build (with tests) takes 8:10 ( https://scans.gradle.com/s/qtbs5qpujlspu ), so it reduces build time from 12min to 8min. The cost here is increased download size: fully cached build downloads 20MiB. https://scans.gradle.com/s/qtbs5qpujlspu/performance/buildCache?cacheDetails=WyJyZW1vdGUtSGl0Il0#remote-hit The top consumers are 4.9MiB :core:javadoc 3.7MiB :core:compileJava Vladimir сб, 25 июл. 2020 г. в 18:30, Vladimir Sitnikov <[email protected] >: > 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 >
