How fast does my internet need to be to use the Gradle Remote Build Cache? (Part 2) Nelson Osacky Follow Apr 13 · 4 min read

In this post well estimating if the remote build cache is worth it using the internals of Gradle. This post is part of a series that dives in the details of whether it is better to rerun tasks locally or download them from the remote build cache on a slow internet connection. Read Part 1 first for the basics of estimating build cache performance.

Diving into Gradle

This post involves a bit of Gradle hackery using internal APIs. If you want to skip straight to the code, here it is. To perform an estimation on your project, scroll to the bottom of this post.

Estimating benefits of the remote build cache

To create a real world estimate for a build we will:

Run a typical build for a project and measure the build duration Create a map of build cache keys for all the tasks in the project Map the build cache keys to tasks which ran Find all recently-added artifacts in the build cache Sum their size Sum of build cache artifacts / build duration = minimum remote cache connection speed

Sounds simple enough? Let’s get to it.

Automating the estimation

Run a typical build for a project

Let’s estimate how long ./gradlew :application:assembleDebug takes.

The first time we run it, it takes 60 seconds. But if we run it again, it only takes 3 seconds because all the tasks are up to date or cached. We need to temporarily disable task caching by forcing a series of Gradle tasks to re-run.

The following code snippet will re-run all SourceTasks in the module:

tasks.withType(SourceTask).configureEach {

outputs.upToDateWhen { false }

}

With this in our buildscript, we can re-run ./gradlew :application:assembleDebug and get a consistent 55 second build duration excluding configuration time.

Create map of build cache keys for all tasks in the project

It sounds straightforward, but unfortunately, there is no public API to get a build cache key for a task.