Setup Cache

Cache Gradle configuration phase outputs. Stop ephemeral CI agents from recomputing them on every run.

Build Scan performance view showing configuration time as part of the overall build timeline.

Feature overview

Setup Cache

Before a build runs, Setup Cache restores a Gradle build's configuration outputs from the Develocity Edge. The cached outputs cover compiled build scripts, dependency accessors, generated API jars, file hashes, and the shared build logic in buildSrc and included builds. That stops ephemeral CI agents from recomputing them on every run, typically cutting configuration time by ~50%. It runs as CI pre- and post-steps, leaving the build untouched. Setup Cache is the only Universal Cache component specific to Gradle Build Tool — the configuration phase it caches is a Gradle construct with no direct equivalent in other build systems. It is most effective alongside Artifact Cache, which supplies the dependencies the configuration phase resolves.

Works great with

Cut Gradle configuration time by ~50% on CI

Cut configuration time on every cold agent — compiled build scripts, dependency accessors, generated API jars, file hashes, and shared build logic from buildSrc are already in place.
As AI multiplies CI build volume, configuration time stays proportional to build logic changes — most runs restore cached outputs rather than recompute.
RoadmapRemote Gradle Configuration Cache will skip the configuration phase entirely on hits, giving ephemeral agents the same reuse as local builds.

Coding agent session showing average configuration time falling 44% after Setup Cache adoption, from 232s to 130s per build.

One configuration output, one cache entry

Recompute only the affected configuration outputs when build logic changes — build scripts, accessors, generated API jars, and file hashes are cached independently.
Restore times stay stable as the project evolves — stale entries are pruned after every build, keeping the cache lean as build logic changes.
Fine-grained storage holds each configuration output once across the CI runner pool, so cache growth tracks actual changes rather than build volume.

A `Setup Cache: Missing artifacts` Build Scan custom value showing only one cached configuration output changed and needed recomputing.

Adopt centrally, with no build-script changes

A standalone Java CLI runs as CI pre- and post-steps; the build tool is untouched and no repo opts in by editing build logic.
CI-agnostic across Jenkins, GitHub Actions, GitLab, TeamCity, and custom runners — one Edge backend serves any mix.
Skip buildSrc and included build recompilation — a baseline across every project, delivered from the CI pipeline regardless of Build Cache adoption.

GitHub Actions job log showing Develocity Setup Cache Restore and Store steps wrapping an unmodified Gradle build.

Observability

Know exactly where configuration time goes

Open any Build Scan to see each configuration step's cost — script compilation, building included plugins, model configuration, task graph calculation, and configuration resolution.
Quantify build logic volatility — the Build Scan custom values show the miss-to-hit ratio per build.
Inspect the restore duration and download size of configuration outputs — spot when restore overhead is cutting into the savings.

Build Scan showing configuration phase duration and per-step breakdown.

Analytics

Project the savings, then measure it

Measure configuration time before rollout and compare it after — the Develocity Analytics MCP Server delivers both states in plain language.
Pinpoint configuration time regressions — surface when and where configuration phase duration degraded across CI.
Identify which projects have the highest miss rates — surface volatile build logic across the organization.