How do you turn the Gradle build cache on, and what is the simplest way to make it the default for everyone on the project?
answer
- off by default
- org.gradle.caching=true in gradle.properties
- --build-cache / --no-build-cache per run
- committed = team-wide default
- enabling != cache hits
basics
~10 sSet org.gradle.caching=true in the project's gradle.properties so it is on for every build and every developer, or pass --build-cache on a single command to enable it just for that run.
solid answer
~30 sThe build cache is **off by default**. You enable it per invocation with `--build-cache` (or `-Dorg.gradle.caching=true`), but the durable, team-wide way is to set `org.gradle.caching=true` in the project's checked-in `gradle.properties`. Because that file is committed, every developer and CI agent gets caching without remembering a flag. A developer can still override it for one run with `--no-build-cache` if they want a clean, cache-free build. The property only switches the *machinery* on; you still need cacheable tasks and a configured cache backend (the local cache is on by default once caching is enabled) to actually get hits.
code
bash · 8 lines# one-off run
./gradlew build --build-cache
# disable for a single run even if the property is set
./gradlew build --no-build-cache
# team-wide: commit this line in gradle.properties
# org.gradle.caching=truego deeper
Know the cache is off by default and that org.gradle.caching=true in gradle.properties turns it on; recall --build-cache for a single run.
Explain the three switches and why committing the property is the team-wide answer; note enabling alone does not guarantee hits.
Distinguish the build cache from incremental up-to-date checks, and explain that cacheable tasks plus a backend are still required.
Frame enabling as the first step of a caching strategy spanning local + remote backends, CI seeding, and reproducibility governance across the org.
## What the build cache is Gradle's **build cache** stores the *outputs* of tasks keyed by their *inputs*. When you run a task whose inputs (sources, classpath, task properties, Gradle version, etc.) hash to a key already present in the cache, Gradle skips execution and unpacks the stored outputs instead. This is different from the **incremental build / up-to-date checks**, which only avoid re-running a task whose outputs already exist *in the current build directory*. The cache works across `clean` builds, across machines, and across branches. ## It is off by default Unlike the up-to-date mechanism (always on), the build cache must be explicitly enabled. There are three switches, in increasing order of permanence: 1. **Command line, one run:** `--build-cache` enables it; `--no-build-cache` disables it. The flag always wins over the property for that invocation. 2. **System property:** `-Dorg.gradle.caching=true` — equivalent, usable anywhere a system property is accepted. 3. **`gradle.properties`:** `org.gradle.caching=true`. This is the canonical, team-wide answer because the file is committed to the repo, so the setting travels with the project. ## Why `gradle.properties` is the right default A committed `org.gradle.caching=true` means new clones, every developer, and CI all get caching with **no per-command flag to remember**. It is reproducible and discoverable in version control. Putting it only in a personal `~/.gradle/gradle.properties` would enable it for *you* but silently leave it off for teammates and CI — a common gotcha. ## Enabling vs. actually getting hits Enabling caching does not by itself produce cache hits. You also need: - **Cacheable tasks** (built-in JVM compile/test tasks are cacheable; custom tasks need `@CacheableTask`). - **A cache backend** — the *local* directory cache is automatically active once caching is on; a remote cache is opt-in. So `org.gradle.caching=true` is necessary but not sufficient. ```properties # gradle.properties (committed to the repo) org.gradle.caching=true ```
- Is the build cache on by default in Gradle?No. The local up-to-date/incremental mechanism is always on, but the build cache itself is off until you enable it via the flag, system property, or org.gradle.caching=true.
- If you enable caching but get zero cache hits, what could be missing?The tasks may not be cacheable, the inputs may differ between runs (so keys never match), or there is no shared backend. Enabling only turns the machinery on; cacheable tasks plus a populated backend produce the hits.
saying these in an interview costs you the question
- Saying the build cache is on by default — it is not.
- Putting org.gradle.caching only in ~/.gradle/gradle.properties and assuming the whole team benefits.
- Confusing the build cache with up-to-date/incremental builds.