Beyond incremental builds described in
up-to-date checks
, Gradle can save time by reusing outputs from previous executions of a task by matching inputs to the task.
Task outputs can be reused between builds on one computer or even between builds running on different computers via a build cache.
We have focused on the use case where users have an organization-wide remote build cache that is populated regularly by continuous integration builds.
Developers and other continuous integration agents should load cache entries from the remote build cache.
We expect that developers will not be allowed to populate the remote build cache, and all continuous integration builds populate the build cache after running the
clean
task.
For your build to play well with task output caching it must work well with the
incremental build
feature.
For example, when running your build twice in a row all tasks with outputs should be
UP-TO-DATE
.
You cannot expect faster builds or correct builds when enabling task output caching when this prerequisite is not met.
Let us start with a project using the Java plugin which has a few Java source files. We run the build the first time.
> gradle --build-cache compileJava
:compileJava
:processResources
:classes
:jar
:assemble
BUILD SUCCESSFUL
We see the directory used by the local build cache in the output. Apart from that the build was the same as without the build cache.
Let’s clean and run the build again.
> gradle clean
:clean
BUILD SUCCESSFUL
> gradle --build-cache assemble
:compileJava FROM-CACHE
:processResources
:classes
:jar
:assemble
BUILD SUCCESSFUL
Now we see that, instead of executing the
:compileJava
task, the outputs of the task have been loaded from the build cache.
The other tasks have not been loaded from the build cache since they are not cacheable. This is due to
:classes
and
:assemble
being
lifecycle tasks
and
:processResources
and
:jar
being Copy-like tasks which are not cacheable since it is generally faster to execute them.