# Introducing Gradle Build Cache Beta

DevFeed: [Introducing Gradle Build Cache Beta](<https://devfeed.tech/articles/introducing-gradle-build-cache-beta-24652.md>)

Original publisher: [Read original article](<https://blog.gradle.org/introducing-gradle-build-cache>)

Author: Sterling Greene

Published: 2017-04-10T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [build performance](<https://devfeed.tech/topics/build-performance.md>), [ci](<https://devfeed.tech/topics/ci.md>)

Tags: [build-performance](<https://devfeed.tech/tags/build-performance.md>), [cache](<https://devfeed.tech/tags/cache.md>), [continuous-integration](<https://devfeed.tech/tags/continuous-integration.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [hashing](<https://devfeed.tech/tags/hashing.md>)

## AI overview

The article introduces the Gradle Build Cache Beta, which reuses task outputs locally and shares them between machines to reduce build times.

## Source excerpt

Introduced in Gradle 3.5 to reduce build time. What does it do? The build cache reuses the outputs of Gradle tasks locally and shares task outputs between machines. In many cases, this will accelerate the average build time. The build cache is complementary to Gradle's incremental build features, which optimizes build performance for local changes that have not been built already. Many Gradle tasks are designed to be incremental, so that if the inputs and outputs of the task do not change, Gradle can skip the task. Even when the task's inputs have changed, some tasks can rebuild only the parts that have changed. Of course, these techniques only work if there are already outputs from previous local builds. In the past, building on fresh checkouts or executing "clean" builds required building everything from scratch again, even if the result of those builds had already been created locally or on another machine (such as the continuous integration server). Now, Gradle uses the inputs of a task as a key to uniquely identify the outputs for a task. With the build cache feature enabled, if Gradle can find that key in a build cache, Gradle will skip task execution and directly copy the outputs from the cache into the build directory. This can be much faster than executing the task again. In particular, if you're using a continuous integration server, you can configure Gradle to push task outputs to a shared build cache. When a developer builds, task outputs already built on CI are copied to the developer's machine. This can greatly improve the developer's local build experience. When using the local build cache, instead of rebuilding large parts of the project whenever you switch branches, Gradle can skip task execution and pull the previous outputs from the local cache. How does it work? A cacheable Gradle task is designed to declare everything that can affect the output of the task as an input. Gradle calculates a build cache key by hashing over all of the inputs to a ta