Chapter 15. Build Cache

Table of Contents

15.1. Overview
15.2. Task Output Caching

This feature is a work in progress. There is no public API for enabling or using a build cache; although, you may see references to it while we build the underlying infrastructure.

15.1. Overview

Build caching is a new kind of cache mechanism that aims to save time by reusing outputs produced by other builds.

15.2. Task Output Caching

Beyond incremental builds described in Section 19.9, “Up-to-date checks (AKA Incremental Build)”, 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.

This feature is a work in progress. There is no public API or documentation for enabling it yet.

15.2.1. Making builds faster

Since a task describes all of its inputs and outputs, Gradle can compute a cache key that uniquely defines the task's outputs based on its inputs. That cache key is used to request previous outputs from a build cache or push new outputs to the build cache. If the previous build is already populated 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 cache key for a task:

  • The task type and its classpath
  • The names of the output properties
  • The names and values of properties annotated as described in the section called “Custom task types”
  • The names and values of properties added by the DSL via 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 @CacheableTask annotation. Many built-in Gradle task types are cacheable, but custom task types are not cacheable by default.