Enable Gradle build and configuration caching

[jwren]

Enabling org.gradle.caching allows Gradle to reuse task outputs from previous builds, significantly reducing build times for incremental builds. Enabling org.gradle.configuration-cache caches the result of the configuration phase, skipping the evaluation of the build script when no configuration changes are detected.

These optimizations reduced local build verification time from ~1m 7s to ~46s.

Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

[helin24]

Note that we may want to get in the habit of running ./gradlew clean more often to avoid getting into weird cache states.

[pq]

This looks great! Do a bit of poking around and a query to gemini, there are a few downsides that would be worth mitigating.

Specifically,

And some advice:

It seems like avoiding caching on rundIde could help avoid debugging confusion. Also, double checking that we won't get confused when re-generating the grammar-kit bits would be good?

---

Process aside: another thing to consider adding to your prompt is something along the lines of: "Are there any possible downsides to XYZ? Evaluate and propose remedies"

[jwren]

@pq The Flutter IJ plugin doesn't use Grammar-Kit (and never will). The Dart IJ Plugin does, a PR like this, flutter/dart-intellij-third-party#180, would prevent any issue with caching.

From my experience clearing your cache (thanks you @helin24) is par the course with or without this setting. These are the simplest of the "please do the right thing" kinds of settings for a healthy project.

Also keep in mind that the presubmits would catch any bad caching from our local machines as well.

[pq]

The Flutter IJ plugin doesn't use Grammar-Kit (and never will).

Good catch. I was getting my repos mixed up! 😬

From my experience clearing your cache (thanks you @helin24) is par the course with or without this setting.

Could you elaborate? Why cache in places if we're just going to clear it? Do mean specifically for runIde?

Also keep in mind that the presubmits would catch any bad caching from our local machines as well.

Cool! Could you explain?

Thanks!

[jwren]

The Flutter IJ plugin doesn't use Grammar-Kit (and never will).

Good catch. I was getting my repos mixed up! 😬

From my experience clearing your cache (thanks you @helin24) is par the course with or without this setting.

Could you elaborate? Why cache in places if we're just going to clear it? Do mean specifically for runIde?

Without cacheing something already, a single build or verify would take an hour or more (think downloading and keeping the IJ platform versions on disk).

I mean this honestly more in jest from my own experience, every few weeks it is a requirement with my machines and these projects to clear my own ./gradle cache just to be able to keep my disk usage down, not see weird errors, etc.

Also keep in mind that the presubmits would catch any bad caching from our local machines as well.

Cool! Could you explain?

Our presubmit machines aren't configured to cache across sessions.

Thanks!

[helin24]

Regarding ./gradlew clean, I don't have much additional information on this. I just recall that in the past (we may have had this setting on before, I'm not sure) there were a number of scenarios where cleaning helped avoid weird states from previous runs. So I am primarily thinking of runIde.

[pq]

Let's land this. If we hit snags w/ runIde, I think we can pass --no-configuration-cache to it and be in business. Happy to wait and see though.