skip to content

For the org.gradle.* performance flags, how do you override a persistent gradle.properties setting for a single build, and what are the CLI equivalents?

level: middleimportance: should knowfreq 45%

answer

  1. CLI overrides file for one run
  2. --no- forms disable persistent features
  3. --build-cache / --no-build-cache
  4. --configuration-cache / --no-configuration-cache
  5. defaults in gradle.properties, overrides on CLI

basics

~10 s

Each org.gradle.* behavior flag has a matching command-line switch with a --no- form to turn it off: --parallel/--no-parallel, --build-cache/--no-build-cache, --configuration-cache/--no-configuration-cache, --configure-on-demand. CLI overrides the file for that run.

solid answer

~30 s

The org.gradle.* performance flags set defaults in `gradle.properties`, but you can override any of them for a single invocation with their CLI switches, which take precedence for that run: - `org.gradle.parallel` ↔ `--parallel` / `--no-parallel` - `org.gradle.caching` ↔ `--build-cache` / `--no-build-cache` - `org.gradle.configuration-cache` ↔ `--configuration-cache` / `--no-configuration-cache` - `org.gradle.configureondemand` ↔ `--configure-on-demand` The `--no-` variants are how you disable a feature that is persistently enabled (e.g. debugging a suspected cache correctness issue with `--no-build-cache`). This is useful for one-off diagnostics without editing files. Project-wide defaults belong in `gradle.properties`; per-run CLI flags are for experiments, CI matrix variations, and troubleshooting.

code

bash · 1 line
bash
./gradlew build --no-build-cache --no-parallel --no-configuration-cache

go deeper

for a junior

Know each flag has a --flag CLI form for one-off runs.

for a middle

Map each property to its --flag/--no-flag pair and explain CLI-overrides-file for a single invocation.

for a senior

Use --no- forms for diagnostics and reason about where defaults belong (checked-in gradle.properties) vs CLI experiments.

for a principal

Standardize defaults in version-controlled gradle.properties org-wide and reserve CLI overrides for CI matrix and troubleshooting.

## File defaults vs per-invocation overrides The org.gradle.* flags in `gradle.properties` are **project (or user) defaults** applied to every build. The command line lets you change behavior for **one invocation** without touching the file, and the CLI value wins for that run. ## The mapping | gradle.properties | CLI enable | CLI disable | |---|---|---| | org.gradle.parallel=true | --parallel | --no-parallel | | org.gradle.caching=true | --build-cache | --no-build-cache | | org.gradle.configuration-cache=true | --configuration-cache | --no-configuration-cache | | org.gradle.configureondemand=true | --configure-on-demand | (no standard --no- form; set property false) | ## Why the --no- forms matter When a feature is on by default, the `--no-` switch is the clean way to turn it off for diagnostics. Classic example: a build behaving oddly might be hiding a task with under-declared inputs. Running `./gradlew build --no-build-cache --rerun-tasks` forces fresh execution to isolate whether the cache is at fault. Similarly `--no-configuration-cache` checks whether a config-cache incompatibility explains a problem, and `--no-parallel` rules out a coupling bug. ```bash # gradle.properties enables caching + parallel; disable both for one diagnostic run ./gradlew build --no-build-cache --no-parallel # enable the configuration cache just to test compatibility ./gradlew assemble --configuration-cache ``` ## Where defaults should live Stable, team-wide choices (enable caching, enable parallel) belong in the checked-in `gradle.properties` so every developer and CI agent behaves the same. Reserve the CLI flags for experiments, troubleshooting, and CI jobs that intentionally vary one dimension.

  • You suspect a stale build cache is causing wrong output. Which one-off command isolates the cache?
    ./gradlew <task> --no-build-cache --rerun-tasks forces the tasks to execute fresh, bypassing both cache hits and up-to-date checks, so you can compare against the cached result.
  • Where should a team put 'always enable the build cache' so everyone is consistent?
    In the checked-in gradle.properties (org.gradle.caching=true), not on the CLI, so every developer and CI agent shares the same default.

saying these in an interview costs you the question

  • Claiming gradle.properties always wins over the CLI for these flags — the per-run CLI switch takes precedence.
  • Forgetting the --no- forms exist for disabling persistently-on features.
  • Putting volatile per-run experiments into the shared gradle.properties.

context

resolving links…