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

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

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

Author: Louis Jacomet

Published: 2026-07-09T04:00:00Z

Content type: tutorial

Language: en

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

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [benchmarking](<https://devfeed.tech/topics/benchmarking.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Docker](<https://devfeed.tech/topics/docker.md>), [Spring Boot](<https://devfeed.tech/topics/spring-boot.md>)

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

## AI overview

This tutorial explains how to optimize Gradle's Execution phase in ephemeral CI environments, focusing on the Gradle Build Cache and task-output reuse. It describes benchmarking a small Spring Boot project in a Docker environment and cautions that the measurements are approximate and specific to Gradle 9.5.1 and the stated test setup.

## Source excerpt

In Part 1 and Part 2, we optimized Gradle's Startup and Configuration phases on ephemeral CI. In this final part, we reach the Execution phase: the point where Gradle checks whether task outputs can be reused and, when they cannot, runs the selected tasks. This is where the Gradle Build Cache becomes the main lever. Benchmarking Performance in Ephemeral CI The methodology is unchanged from Part 1 and Part 2: 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 execution-phase optimizations for one small Spring Boot project, one Gradle version, one JDK image, and one local Docker environment. Larger builds, especially multi-module builds with expensive compilation, testing, code generation, or packaging tasks, will generally see bigger gains from task-output reuse than this 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. The baseline (no optimizations) averaged 32.3s over ten runs, in line with the ~31.5s baselines from Parts 1 and 2. Optimizations for the Execution Phase During the Execution phase, Gradle runs the task graph that was selected and ordered during configuration. For each task, Gradle decides whether work can be avoided before it executes task actions: Input and output snapshotting: Gradle fingerprints the task's declared inputs, outputs, and relevant implementation details. Reuse checks: Gradle determines whether the task is already up to date locally, or whether matching outputs can be loaded from the Build Cache. Task action execution: Gradl