It might be nice to make Gradle caching more testable in CI. Such as as build parameter that runs each task twice and ensures only allow-listed tasks are rebuilt.
On Wed, Jan 26, 2022, 17:40 Cédric Champeau <cedric.champ...@gmail.com> wrote: > Hi folks, > > It seems that since last time I updated the build, caching is broken: if > you run the same build twice, it's not fetching compileGroovy from cache, > which it should. If you update the build, please make sure that you don't > break caching by: > > - running the same command twice in a row and making sure everything is > up-to-date > - running "clean whatever" and make sure it fetches everything from the > local cache > > if it doesn't work, you broke something. As an example, I checked out the > GROOVY_4_0_0 tag and ran `./gradlew compileGroovy`. > > Here's the first scan: https://scans.gradle.com/s/bo5tzjdgrvhrm > > Then I'm doing the same again: > https://scans.gradle.com/s/2muqflkbj6iwo/timeline?details=ajpf6vqhnqhfc > > You can see that everything gets recompiled because the bootstrap compiler > jar changed. This should never happen. I don't know how this got unnoticed, > since it's obviously dramatically increasing feedback time. > > This is also particularly painful because the build OOMs when trying to > publish to a local repository. Because it has to restart from scratch, it's > a huge waste of time. > > I'll try to find time to identify the problem. FWIW, this is why a Gradle > Enterprise partnership would be useful, since we'd get build data and the > problem would have been immediately identified. >
