skip to content

If gradle.properties has org.gradle.caching=true but a build is invoked with --no-build-cache, what happens, and how do the command-line flag, system property, and gradle.properties relate?

level: middleimportance: should knowfreq 45%

answer

  1. flag > system property > gradle.properties > default(off)
  2. --no-build-cache wins over org.gradle.caching=true
  3. override is per-run, not persistent
  4. no-build-cache does not clear stored entries

basics

~10 s

The command-line flag wins. --no-build-cache disables caching for that run despite the property. The --build-cache/--no-build-cache flag overrides org.gradle.caching, which overrides the default (off).

solid answer

~30 s

Gradle resolves the caching switch in a precedence order: the **command-line flag** (`--build-cache` / `--no-build-cache`) has the highest priority, then the **system property** `-Dorg.gradle.caching`, then the **`org.gradle.caching` property** in `gradle.properties`, and finally the **default**, which is off. So with `org.gradle.caching=true` committed, running `./gradlew build --no-build-cache` disables the cache for that single invocation — useful for a deliberately clean, reproducible build or to debug a suspected stale-cache problem. The next run without the flag goes back to honoring the property. This layering lets a team set a sane default in version control while still letting any individual run opt out.

code

bash · 6 lines
bash
# gradle.properties: org.gradle.caching=true

./gradlew build                 # cache ON  (property)
./gradlew build --no-build-cache # cache OFF (flag wins, this run only)
./gradlew build -Dorg.gradle.caching=false # cache OFF via system property
./gradlew build                 # cache ON again (back to property)

go deeper

for a junior

Know that the command-line flag overrides the gradle.properties setting for that run.

for a middle

State the full precedence order and explain the per-run override semantics.

for a senior

Explain practical uses — forcing clean builds for debugging stale entries or deterministic release runs — and that the override does not mutate the file or clear entries.

for a principal

Discuss how this layering enables a committed org default plus controlled local overrides without sacrificing reproducibility governance.

## The layered switch Gradle exposes a single boolean — "is the build cache enabled?" — but it can be set from several places. When they disagree, Gradle applies a fixed precedence: 1. **Command-line flags** `--build-cache` / `--no-build-cache` — highest priority. Whatever you type on the command line wins for that invocation. 2. **System property** `-Dorg.gradle.caching=true|false` — for example passed on the command line as `-D...` or via `GRADLE_OPTS`. 3. **Project property** `org.gradle.caching` in `gradle.properties` (project-level, then `~/.gradle/gradle.properties`). 4. **Default** — disabled. ## Why this matters The committed property gives the team a default of *on*. The override flag gives any single run an escape hatch: - `--no-build-cache` forces a from-scratch build, which is handy when you suspect a poisoned or stale cache entry and want to rule the cache out, or when you want a fully deterministic clean build in a release pipeline. - `--build-cache` does the opposite — turns it on for one run when the project default is off (for instance, an older repo that has not committed the property yet). ## A mental model Think of `gradle.properties` as the standing policy and the flag as a one-time override. The override does not change the file; the next plain invocation reverts to the standing policy. ## Common confusion Developers sometimes expect `--no-build-cache` to *clear* the cache. It does not — it only skips using/populating the cache for that run. The stored entries remain on disk; cleaning the directory is a separate concern from toggling the switch. ```bash # property says on; this single run is forced off ./gradlew test --no-build-cache # next run honors the property again (on) ./gradlew test ```

  • Does --no-build-cache delete the cached entries?
    No. It only skips reading from and writing to the cache for that invocation. Existing entries stay on disk; removing them is a separate cleanup action.
  • Where does a system property -Dorg.gradle.caching sit in the precedence?
    Below the explicit --build-cache/--no-build-cache flag but above the gradle.properties value and the default-off.

saying these in an interview costs you the question

  • Claiming the gradle.properties value overrides the command-line flag (it is the reverse).
  • Saying --no-build-cache clears or invalidates the cache contents.

context

resolving links…