# Improvements in the Build Configuration Input Tracking

DevFeed: [Improvements in the Build Configuration Input Tracking](<https://devfeed.tech/articles/improvements-in-the-build-configuration-input-tracking-24646.md>)

Original publisher: [Read original article](<https://blog.gradle.org/improvements-in-the-build-configuration-input-tracking>)

Author: Mikhail Lopatkin

Published: 2023-09-01T04: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>), [build performance](<https://devfeed.tech/topics/build-performance.md>), [Caching](<https://devfeed.tech/topics/caching.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [build-performance](<https://devfeed.tech/tags/build-performance.md>), [build-tool](<https://devfeed.tech/tags/build-tool.md>), [cache-invalidation](<https://devfeed.tech/tags/cache-invalidation.md>), [caching](<https://devfeed.tech/tags/caching.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [environment-variables](<https://devfeed.tech/tags/environment-variables.md>), [files](<https://devfeed.tech/tags/files.md>), [gradle](<https://devfeed.tech/tags/gradle.md>)

## AI overview

This article explains improvements in Gradle's build configuration input tracking. It describes how the configuration cache fingerprints build scripts, dependencies, environment values, files, filesystem information, and external-process output, then rechecks those inputs to determine whether cached configuration results can be reused safely.

## Source excerpt

The configuration cache is a feature that significantly improves build performance by caching the result of the configuration phase and reusing it for subsequent builds. Using the configuration cache, the Gradle Build Tool can skip the configuration phase entirely when nothing that affects the build configuration, such as build scripts, has changed. In Gradle 8.1, the configuration cache became stable and recommended for adoption. Stability, in this case, means that the behavior is finalized, and all breaking changes follow the Gradle deprecation process. In general, if something works now, it will continue to work the same way--unless the behavior is buggy and may lead to incorrect builds. While some features are not yet implemented, most users can already benefit from the speed-ups brought by the configuration cache. Build configuration inputs When writing configuration-cache-compatible build logic or plugins, it is important to understand what Gradle considers build configuration inputs and how they affect cache invalidation. The concept is similar to task caching: Everything that contributes to the build logic execution is an input. The configuration phase is an action. The resulting task execution graph is the output. Examples of the build configuration inputs are: Build scripts and their dependencies (plugins and libraries). Environment variables and system properties read at configuration time. Files read by the build logic or plugins at configuration time. Information about the file system (existence of files, directory structure) obtained at configuration time. The output of external processes executed at configuration time. When build logic or a plugin reaches out to something "environmental" at configuration time, the obtained data becomes part of the configuration cache fingerprint. Next time the build runs, Gradle checks if the values of the inputs are still the same--it re-reads environment variables, system properties, files, and re-runs external proces