Thanks for looking into this and sharing the outcome. Does this "limitation" apply for both build cache (org.gradle.caching) and configuration cache (org.gradle.configuration-cache)?
Best, Christos On 2026/07/10 18:01:59 David Smiley wrote: > Unfortunately, the improvement isn't seen by GHA runs since our GHA > workflow for Crave tells crave to `--clean` . This favors result > reliability over performance. Ah well. > > On Sat, Jul 4, 2026 at 1:50 AM David Smiley <[email protected]> wrote: > > > I spent some time optimizing the crave build -- took of ~3 minutes by > > using the gradle build cache, which crave retains between builds. I just > > invoked a build that took 7m total in crave, which is quite good. The > > actual change was mostly a tweak to the build image initialization script > > in crave's admin area to put "org.gradle.caching=true" in > > gradle.properties. I also committed a trivial fix/change in > > develocity.gradle to allow this to work. > > > > Future improvments: > > There's 1 minute wasted up front on every build due to the Gradle > > configuration phase in our huge gradle build. Some day maybe we'll > > implement the gradle configuration cache to help here. And there's no > > "work stealing" at the tail end as unlucky workers doing tests finish well > > after others have completed their tasks. So there's room for improvement > > at the front and back ends. I also think breaking up our biggest > > subproject, solr-core, will help. > > > > Perhaps these improvements could also be applied to GHA workflows as well, > > speeding up the precommit checks. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
