Hi all, Polaris now has enough Gradle configuration-cache compatibility work in place that developers can opt in locally if they want to try it.
The cache remains disabled by default in `gradle.properties`. To enable it for your own checkout, create a local `.env` file in the project root: GRADLE_OPTS="-Dorg.gradle.configuration-cache=true" The root `.env` file is ignored by Git and is sourced by `./gradlew`, so this is local to your checkout. A few important caveats: * Do not enable Gradle's configuration cache in Polaris CI. The build now fails early if configuration cache is requested while `CI` is set. * The configuration cache can persist build configuration state to disk, which may include credentials or credential-adjacent values if a task or plugin wires them during configuration. * For normal local development tasks like compile, test, check, and repeated focused module work, that risk is usually low, especially on a single-user development machine. I would still avoid using it for release, publishing, or other credential-heavy workflows unless you have checked what the task graph does. This is not a magic switch that makes every build much faster. The main benefit is avoiding repeated Gradle configuration work for the same or similar task graphs. That tends to help during local development where we repeatedly run focused tests, checks, or compile tasks while iterating. If you try it and hit a configuration-cache problem, please share the task you ran and the reported problem so we can decide whether it is worth fixing in Polaris, reporting upstream, or documenting as a task graph that should stay outside the configuration-cache path. Best, Robert
