Gradle's build cache stores the outputs of tasks keyed by a hash of their inputs, so if the same inputs occur again — even on a different machine or branch — the cached output is reused instead of re-executing the task. This is distinct from incremental builds, which only skip work within a single local build history.
Key Points: • Enable it by setting org.gradle.caching=true in gradle.properties, or passing --build-cache on the command line. • A local cache stores outputs on disk for reuse across local builds; a remote/shared cache lets an entire team and CI reuse each other's task outputs. • Cache hits require tasks to be cacheable (declared with @CacheableTask) and to have properly declared inputs/outputs. • It's especially valuable in CI, where a clean checkout would otherwise force a full rebuild every time — a shared remote cache can turn that into mostly cache hits. • Unlike incremental builds (skip if unchanged locally), the build cache can reuse outputs even when the local build directory was wiped, e.g. between CI agents.
Example: A team enabled a shared remote build cache backed by an internal server; a developer who pulled a colleague's branch found their build finished in seconds because most task outputs were already cached from the colleague's earlier build with identical inputs.
Code Example:
# gradle.properties
org.gradle.caching=trueInterview Tip: A concise interview answer is:
"The build cache stores task outputs keyed by their input hash, so identical inputs reuse a cached result instead of re-running the task, even across different machines if a remote cache is configured. It's especially valuable in CI, where a clean checkout would otherwise mean a full rebuild every single time."