Configuration cache passes locally but breaks in CI pipeline

Goal

Decide whether the production pipeline should enable Gradle's configuration cache, which serializes the task graph at configuration time for faster builds.

Constraints

• Local runs often use a warm Gradle daemon and a populated ~/.gradle directory, while CI agents start cold with a clean GRADLE_USER_HOME.
• Plugins may perform unsupported work at execution time; such plugins work with the traditional configuration phase but fail when the configuration cache is active.
• Tasks that read environment variables, absolute paths, or local files without declaring them as inputs can produce cache hits locally that are invalid in CI.
• Dependency resolution can diverge when local builds rely on cached artifacts or mavenLocal() while CI resolves from remote repositories.

Open questions

1. Should the pipeline adopt the configuration cache given the current plugin compatibility matrix?
2. What verification steps (e.g., clean GRADLE_USER_HOME, --no-daemon, build scans) are required before enabling it in production?
3. How can undeclared task inputs that cause local‑only cache hits be systematically detected?