// Copyright 2017 the original author or authors.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[build_cache]]
== Build Cache

NOTE: The build cache feature described here is different from the https://developer.android.com/studio/build/build-cache.html[Android plugin build cache].

[[sec:build_cache_intro]]
=== Overview

The Gradle _build cache_ is a cache mechanism that aims to save time by reusing outputs produced by other builds.
The build cache works by storing (locally or remotely) build outputs and allowing builds to fetch these outputs from the cache when it is determined that inputs have not changed, avoiding the expensive work of regenerating them.

A first feature using the build cache is _task output caching_.
Essentially, task output caching leverages the same intelligence as <<sec:up_to_date_checks,up-to-date checks>> that Gradle uses to avoid work when a previous local build has already produced a set of task outputs.
But instead of being limited to the previous build in the same workspace, task output caching allows Gradle to reuse task outputs from any earlier build in any location on the local machine.
When using a shared build cache for task output caching this even works across developer machines and build agents.

Apart from task output caching, we expect other features to use the build cache in the future.

NOTE: A complete guide is available about https://guides.gradle.org/using-build-cache/[using the build cache]. It covers the different scenarios caching can improve, and detailed discussions of the different caveats you need to be aware of when enabling caching for a build.

[[sec:build_cache_enable]]
=== Enable the Build Cache

By default, the build cache is not enabled. You can enable the build cache in a couple of ways:

Run with `--build-cache` on the command-line::
Gradle will use the build cache for this build only.
Put `org.gradle.caching=true` in your `gradle.properties`::
Gradle will try to reuse outputs from previous builds for all builds, unless explicitly disabled with `--no-build-cache`.

When the build cache is enabled, it will store build outputs in the Gradle user home.
For configuring this directory or different kinds of build caches see <<sec:build_cache_configure>>.

[[sec:task_output_caching]]
=== Task Output Caching

Beyond incremental builds described in <<sec: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 pull 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 <<sec:up_to_date_checks,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.

Task output caching is automatically enabled when you enable the build cache, see <<sec:build_cache_enable>>.

[[sec:task_output_caching_example]]
==== What does it look like

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 <<sec:lifecycle_tasks,lifecycle tasks>> and `:processResources`
and `:jar` being Copy-like tasks which are not cacheable since it is generally faster to execute them.

[[sec:task_output_caching_details]]
=== Cacheable tasks

Since a task describes all of its inputs and outputs, Gradle can compute a _build cache key_ that uniquely defines the task's outputs based on its inputs.
That build cache key is used to request previous outputs from a build cache or store new outputs in the build cache.
If the previous build outputs have been already stored in the cache by someone else, e.g. your continuous integration server or other developers, you can avoid executing most tasks locally.

The following inputs contribute to the build cache key for a task in the same way that they do for <<sec:how_does_it_work,up-to-date checks>>:

* The task type and its classpath
* The names of the output properties
* The names and values of properties annotated as described in <<sec:task_input_output_annotations>>
* The names and values of properties added by the DSL via api:org.gradle.api.tasks.TaskInputs[]
* The classpath of the Gradle distribution, buildSrc and plugins
* The content of the build script when it affects execution of the task

Task types need to opt-in to task output caching using the `@api:org.gradle.api.tasks.CacheableTask[]` annotation.
Note that `@api:org.gradle.api.tasks.CacheableTask[]` is not inherited by subclasses.
Custom task types are _not_ cacheable by default.

[[sec:task_output_caching_cacheable_tasks]]
==== Built-in cacheable tasks

Currently, the following built-in Gradle tasks are cacheable:

* Java toolchain:
    api:org.gradle.api.tasks.compile.JavaCompile[],
    api:org.gradle.api.tasks.javadoc.Javadoc[]
* Groovy toolchain:
    api:org.gradle.api.tasks.compile.GroovyCompile[],
    api:org.gradle.api.tasks.javadoc.Groovydoc[]
* Scala toolchain:
    api:org.gradle.api.tasks.scala.ScalaCompile[],
    api:org.gradle.language.scala.tasks.PlatformScalaCompile[],
    api:org.gradle.api.tasks.scala.ScalaDoc[]
* Native toolchain:
    api:org.gradle.language.cpp.tasks.CppCompile[],
    api:org.gradle.language.c.tasks.CCompile[],
    api:org.gradle.language.swift.tasks.SwiftCompile[]
* Testing:
    api:org.gradle.api.tasks.testing.Test[]
* Code quality tasks:
    api:org.gradle.api.plugins.quality.Checkstyle[],
    api:org.gradle.api.plugins.quality.CodeNarc[],
    api:org.gradle.api.plugins.quality.FindBugs[],
    api:org.gradle.api.plugins.quality.JDepend[],
    api:org.gradle.api.plugins.quality.Pmd[]
* JaCoCo:
    api:org.gradle.testing.jacoco.tasks.JacocoMerge[],
    api:org.gradle.testing.jacoco.tasks.JacocoReport[]
* Other tasks:
    api:org.gradle.api.plugins.antlr.AntlrTask[],
    api:org.gradle.plugin.devel.tasks.ValidateTaskProperties[],
    api:org.gradle.api.tasks.WriteProperties[]

All other built-in tasks are currently not cacheable.

Some tasks, like api:org.gradle.api.tasks.Copy[] or api:org.gradle.api.tasks.bundling.Jar[], usually do not make sense to make cacheable because Gradle is only copying files from one location to another.
It also doesn't make sense to make tasks cacheable that do not produce outputs or have no task actions.

[[sec:task_output_caching_cacheable_3rd_party]]
==== Third party plugins

There are third party plugins that work well with the build cache.
The most prominent examples are the https://developer.android.com/studio/releases/gradle-plugin.html[Android plugin 3.1+] and the https://blog.gradle.org/kotlin-build-cache-use[Kotlin plugin 1.2.21+].
For other third party plugins, check their documentation to find out whether they support the build cache.

[[sec:task_output_caching_inputs]]
==== Declaring task inputs and outputs

It is very important that a cacheable task has a complete picture of its inputs and outputs, so that the results from one build can be safely re-used somewhere else.

Missing task inputs can cause incorrect cache hits, where different results are treated as identical because the same cache key is used by both executions.
Missing task outputs can cause build failures if Gradle does not completely capture all outputs for a given task.
Wrongly declared task inputs can lead to cache misses especially when containing volatile data or absolute paths.
(See <<sec:task_inputs_outputs>> on what should be declared as inputs and outputs.)

[NOTE]
====
The task path is _not_ an input to the build cache key.
This means that tasks with different task paths can re-use each other's outputs as long as Gradle determines that executing them yields the same result.
====

In order to ensure that the inputs and outputs are properly declared use integration tests (for example using TestKit) to check that a task produces the same outputs for identical inputs and captures all output files for the task.
We suggest adding tests to ensure that the task inputs are relocatable, i.e. that the task can be loaded from the cache into a different build directory (see `@api:org.gradle.api.tasks.PathSensitive[]`).

In order to handle volatile inputs for your tasks consider <<sec:configure_input_normalization,configuring input normalization>>.

[[sec:build_cache_configure]]
=== Configure the Build Cache

You can configure the build cache by using the api:org.gradle.api.initialization.Settings#buildCache(org.gradle.api.Action)[] block in `settings.gradle`.

Gradle supports a `local` and a `remote` build cache that can be configured separately.
When both build caches are enabled, Gradle tries to load build outputs from the local build cache first, and then tries the remote build cache if no build outputs are found.
If outputs are found in the remote cache, they are also stored in the local cache, so next time they will be found locally.
Gradle stores ("pushes") build outputs in any build cache that is enabled and has api:org.gradle.caching.configuration.BuildCache#isPush()[] set to `true`.

By default, the local build cache has push enabled, and the remote build cache has push disabled.

The local build cache is pre-configured to be a api:org.gradle.caching.local.DirectoryBuildCache[] and enabled by default.
The remote build cache can be configured by specifying the type of build cache to connect to (api:org.gradle.caching.configuration.BuildCacheConfiguration#remote(java.lang.Class)[]).

[[sec:build_cache_configure_local]]
==== Built-in local build cache

The built-in local build cache, api:org.gradle.caching.local.DirectoryBuildCache[], uses a directory to store build cache artifacts.
By default, this directory resides in the Gradle user home directory, but its location is configurable.

Gradle will periodically clean-up the local cache directory by removing entries that have not been used recently to conserve disk space.

For more details on the configuration options refer to the DSL documentation of api:org.gradle.caching.local.DirectoryBuildCache[].
Here is an example of the configuration.

++++
<sample id="directoryBuildCacheConfiguration" dir="buildCache/configure-built-in-caches" title="Configure the local cache">
    <sourcefile file="settings.gradle" snippet="configure-directory-build-cache"/>
</sample>
++++


[[sec:build_cache_configure_remote]]
==== Remote HTTP build cache

Gradle has built-in support for connecting to a remote build cache backend via HTTP.
For more details on what the protocol looks like see api:org.gradle.caching.http.HttpBuildCache[].
Note that by using the following configuration the local build cache will be used for storing build outputs while the local and the remote build cache will be used for retrieving build outputs.

++++
<sample id="httpBuildCache" dir="buildCache/http-build-cache" title="Pull from HttpBuildCache">
    <sourcefile file="settings.gradle" snippet="http-build-cache"/>
</sample>
++++

You can configure the credentials the api:org.gradle.caching.http.HttpBuildCache[] uses to access the build cache server as shown in the following example.

++++
<sample id="httpBuildCacheConfiguration" dir="buildCache/configure-built-in-caches" title="Configure remote HTTP cache">
    <sourcefile file="settings.gradle" snippet="configure-http-build-cache"/>
</sample>
++++

[NOTE]
====
You may encounter problems with an untrusted SSL certificate when you try to use a build cache backend with an HTTPS URL.
The ideal solution is for someone to add a valid SSL certificate to the build cache backend, but we recognize that you may not be able to do that.
In that case, set api:org.gradle.caching.http.HttpBuildCache#isAllowUntrustedServer()[] to `true`:

++++
<sample id="httpBuildCacheAllowUntrustedServer" dir="buildCache/http-build-cache" title="Allow untrusted SSL certificate for HttpBuildCache">
    <sourcefile file="settings.gradle" snippet="allow-untrusted-server"/>
</sample>
++++

This is a convenient workaround, but you shouldn’t use it as a long-term solution.
====

[[sec:build_cache_configure_use_cases]]
==== Configuration use cases

The recommended use case for the build cache is that your continuous integration server populates the remote build cache from clean builds while developers load from the remote build cache and store in the local build cache.
The configuration would then look as follows.

++++
<sample id="developerCiSetup" dir="buildCache/developer-ci-setup" title="Recommended setup for CI push use case">
    <sourcefile file="settings.gradle" snippet="developer-ci-setup"/>
</sample>
++++

If you use a `buildSrc` directory, you should make sure that it uses the same build cache configuration as the main build.
This can be achieved by applying the same script to `buildSrc/settings.gradle` and `settings.gradle` as shown in the following example.

++++
<sample id="buildCacheBuildSrc" dir="buildCache/build-src" title="Consistent setup for buildSrc and main build">
    <sourcefile file="settings.gradle" snippet="configure-build-src-build-cache"/>
    <sourcefile file="buildSrc/settings.gradle" snippet="configure-build-src-build-cache"/>
    <sourcefile file="gradle/buildCacheSettings.gradle" snippet="configure-build-src-build-cache"/>
</sample>
++++

It is also possible to configure the build cache from an <<sec:using_an_init_script,init script>>, which can be used from the command line, added to your Gradle user home or be a part of your custom Gradle distribution.

++++
<sample id="buildCacheConfigurationInitScript" dir="buildCache/configure-by-init-script" title="Init script to configure the build cache">
    <sourcefile file="init.gradle" />
    <test args="-I init.gradle"/>
</sample>
++++

[[sec:build_cache_composite]]
==== Build cache and composite builds

Gradle's <<composite_builds, composite build feature>> allows including other complete Gradle builds into another.
Such included builds will inherit the build cache configuration from the top level build,
regardless of whether the included builds define build cache configuration themselves or not.

The build cache configuration present for any included build is effectively ignored, in favour of the top level build's configuration.
This also applies to any `buildSrc` projects of any included builds.

[[sec:build_cache_setup_http_backend]]
=== How to set up an HTTP build cache backend

Gradle provides a Docker image for a https://hub.docker.com/r/gradle/build-cache-node/[build cache node], which can connect with Gradle Enterprise for centralized management.
The cache node can also be used without a Gradle Enterprise installation with restricted functionality.

[[sec:build_cache_implement]]
=== Implement your own Build Cache

Using a different build cache backend to store build outputs (which is not covered by the built-in support for connecting to an HTTP backend) requires implementing
your own logic for connecting to your custom build cache backend.
To this end, custom build cache types can be registered via api:org.gradle.caching.configuration.BuildCacheConfiguration#registerBuildCacheService(java.lang.Class,java.lang.Class)[].
For an example of what this could look like see the https://github.com/gradle/gradle-hazelcast-plugin[Gradle Hazelcast plugin].

https://gradle.com/build-cache[Gradle Enterprise] includes a high-performance, easy to install and operate, shared build cache backend.
