Allow progressive adoption of the configuration cache

[eskatos]

Current Behavior

One can enable the configuration cache and the build will fail if validation problems are found.
Once enabled it means that use cases that are not supported will fail and require users to disable the configuration cache for just those use cases using for example --no-configuration-cache. Asking build users to remember which use cases aren't supported yet doesn't scale and causes friction to adopt the configuration cache.

One can also turn problems into warnings and let the build continue in the presence of problems but then the build may fail in bad ways.

This is good enough for experimentation and problem discovery.
But, this is not enough to allow progressive adoption by teams.

This issue is about introducing a mechanism that would allow teams to progressively adopt the configuration cache by disabling the configuration cache for unsupported use cases. With such a mechanism in place teams can turn the configuration cache on persistently without breaking use cases that are not supported yet.

Expected Behavior

Build authors can declare what is unsupported and Gradle will disable the configuration cache if an unsupported use case is requested.

The exact form of the declaration is to be defined. For example it could be that build authors declare the tasks (e.g. by type) that are unsupported and Gradle will disable the configuration cache whenever they appear in the selected task graph. There are other options such as declaring a plugin as unsupported so that Gradle can treat both its configuration time build logic and contributed tasks as unsupported.

Gradle would assume that anything that isn't declared as unsupported must work. In other words, problems detected in unsupported tasks would be reported as e.g. warnings instead of errors and would not fail the build. But problems detected in expected to be supported tasks would be reported as problems failing the build.

Context

The need for such a feature has been expressed by several teams, community members and the Gradle team itself.

[autonomousapps]

Is it necessary that unsupported tasks be explicitly declared as such? This would be even easier, even transparent, if Gradle would gracefully fallback when it encountered a problem. Even if that meant restarting the build from the beginning, it would be better than failing.

[liutikas]

Explicit list is great as a baseline for making sure no new tasks regress into being incompatible with configuration caching as project are in this transition period where some of the tasks support configuration caching and some dont.

[eskatos]

Implementation for this can now be tested with a 7.4 nightly.
You can use this repository to try it out.

[marcphilipp]

@eskatos How does one use/configure it?

[eskatos]

@marcphilipp, see https://docs.gradle.org/nightly/userguide/configuration_cache.html#config_cache:task_opt_out

[eskatos]

This will be in 7.4-RC1

[autonomousapps]

Huh, I thought we were getting support for an allow-list of tasks that were compatible, rather than an opt-out mechanism. Not necessarily disagreeing, but I'm curious why the change in direction?

[eskatos]

The goal is to eventually make CC the default and all tasks compatible. An opt-out felt natural in this regard. You'll want to remove opt-outs progressively during adoption and work towards having none. Note that the description of this issue is about just that, declaring what isn't supported.

Please give it a try when RC1 is out and provide feedback.