# Essential Tips for Gradle on Ephemeral CI Environments - Part 2

DevFeed: [Essential Tips for Gradle on Ephemeral CI Environments - Part 2](<https://devfeed.tech/articles/essential-tips-for-gradle-on-ephemeral-ci-environments-part-2-24632.md>)

Original publisher: [Read original article](<https://blog.gradle.org/gradle-on-ephemeral-ci-2>)

Author: Louis Jacomet

Published: 2026-07-08T04: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>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Spring Boot](<https://devfeed.tech/topics/spring-boot.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [GitHub](<https://devfeed.tech/topics/github.md>)

Tags: [benchmarking](<https://devfeed.tech/tags/benchmarking.md>), [build-performance](<https://devfeed.tech/tags/build-performance.md>), [cache](<https://devfeed.tech/tags/cache.md>), [docker](<https://devfeed.tech/tags/docker.md>), [github](<https://devfeed.tech/tags/github.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [jdk](<https://devfeed.tech/tags/jdk.md>), [spring-boot](<https://devfeed.tech/tags/spring-boot.md>)

## AI overview

Part 2 examines Gradle configuration-phase performance in ephemeral CI environments, focusing on dependency and script caching and the roles of the setup-gradle GitHub Action and Develocity Universal Cache.

## Source excerpt

In Part 1, we explored foundational strategies for improving Gradle build performance in ephemeral CI environments, focusing on the Startup and Initialization phase. Now, in Part 2, we shift our focus to the Configuration phase: the work Gradle does after startup but before it executes any tasks. We'll benchmark dependency and script caching, then look at where the setup-gradle GitHub Action and Develocity's Universal Cache fit. Benchmarking Performance in Ephemeral CI The methodology is the same as in Part 1: each scenario builds a fresh Docker image of the Spring Boot Project with --no-cache, base images are pre-pulled, and every figure is the average of ten runs against one consistent baseline. Individual runs vary by a second or two, so read small differences as approximate rather than exact. These numbers are not intended as universal Gradle performance claims. They show the relative impact of configuration-phase optimizations for one small Spring Boot project, one Gradle version, one JDK image, and one local Docker environment. Larger builds, with more dependencies and more build logic, will generally see bigger gains from dependency and script caching than a small sample project does. NOTE: All measurements in this post are pinned to Gradle 9.5.1. If you repeat the experiment with a newer Gradle version, rebuild the prime image and update any version-specific cache paths accordingly. One difference from Part 1: for the Configuration phase, we prime the cache by building the complete Spring Boot Project, not the empty Prime Project. Caching configuration-phase work only means something when there are real dependencies and real build scripts to cache, so the prime image must reflect a realistic project. As in Part 1, that prime image is built once and only restored from, so the timed builds measure cache restore, not cache creation. Building the full project populates the following directories in the Gradle User Home: .gradle/ <-- Gradle User Home (default: ~/.