Skip to content

Ensuring Configuration Cache compatibility#

The configuration and execution phase of builds always take the longest. You may already know about the build cache, which saves execution time by reusing outputs from past builds. Gradle's Configuration Cache, introduced in 6.6 and becoming a preferred mode of execution in Gradle 10, reuses configuration results from past builds to speed up the configuration phase.

If you keep an eye on Gradle public roadmap updates, you've probably noticed lots of improvements in Configuration Cache, and steady adoption in the ecosystem. Still, there is a lot of work to be done in the plugins. Many Gradle plugins still need to have configuration cache compatibility, and also updates might be needed in end user builds and convention plugins. For the community plugins for Gradle, we track the status on this GitHub Issue, and any contributions are more than welcome!

On this page, we focus on tips for plugins developers and contributors who want to fix Configuration Cache (CC) compatibility in their projects.

Main Documentation#

For Configuration Cache adoption and troubleshooting steps, you can already find information in the main documentation:

FAQ#

How to fix "invocation of 'Task.project' at execution time is unsupported"?#

In essence, you should use an alternative service that provides similar functionality. See "Using the Project object" in the Configuration Cache documentation. See a sample fix.

Also, the configuration cache serialization logic handles Provider<T> specially and correctly serializes their values; use Property<T> and the providers returned from org.gradle.api.provider.ProviderFactory to store values captured from the project or the properties.

How to fix "cannot serialize Gradle script object references"?#

This problem most commonly signals that a member of the enclosing script scope, for instance, a member of the Project object in the case of project scripts, is being used by a task action:

tasks.register("printProjectVersion") {
    doLast {
        println(version) // <---- Project.version captured by a task action
    }
}

A common example is when the configurations property or a configuration object (like runtimeClasspath) is used by a doLast/doFirst action. Avoid accessing such objects during execution. See a fix.