skip to content

Walk me through the CLI flags that change Gradle's log verbosity and what each one does.

level: juniorimportance: must knowfreq 50%

answer

  1. -q quiet, -i info, -d debug
  2. -i = incremental/cache debugging
  3. last flag wins, one level active
  4. stacktrace flags are separate
  5. -d adds timestamps + threads

basics

~10 s

-q/--quiet shows only errors and important messages; -i/--info adds informational detail like up-to-date reasons; -d/--debug shows everything including internals and timestamps. No flag means the default LIFECYCLE level.

solid answer

~40 s

Gradle exposes its log levels through short and long CLI flags. **`-q` / `--quiet`** drops you to QUIET: almost silent, just errors and `println`-style important messages. **`-i` / `--info`** raises to INFO: you see *why* tasks ran or were skipped (UP-TO-DATE, FROM-CACHE), dependency resolution notes, and lifecycle-callback hints — invaluable for diagnosing incremental-build misses. **`-d` / `--debug`** is DEBUG: the firehose — every internal message, full dependency resolution, plus a timestamp and thread on each line. The default (no flag) is LIFECYCLE. Only one level can be active; if you pass several, the **last one wins**. Separately, `-s`/`--stacktrace` and `-S`/`--full-stacktrace` control *exception detail* on failure, not the log level — they are orthogonal and can combine with any verbosity flag.

code

bash · 3 lines
bash
gradle build -i      # INFO: up-to-date reasons, cache hits
gradle build -q      # QUIET: near-silent
gradle build -d      # DEBUG: full firehose with timestamps

go deeper

for a junior

Map each short flag to its level: -q quiet, -i info, -d debug; no flag = LIFECYCLE.

for a middle

Explain that -i is the go-to for debugging incremental builds and cache misses, with concrete examples.

for a senior

Note last-flag-wins, that DEBUG adds timestamps/threads, and that stacktrace flags are orthogonal.

for a principal

Recommend verbosity conventions for local vs CI and caution that DEBUG output volume can affect build/log costs.

## The verbosity flags | Long form | Short | Level | What you get | |-----------|-------|-------|--------------| | `--quiet` | `-q` | QUIET | Errors + important messages only; near-silent. | | (none) | — | LIFECYCLE | Default: task progress + build result. | | `--info` | `-i` | INFO | Why tasks ran/were skipped, cache hits, resolution notes. | | `--debug` | `-d` | DEBUG | Everything, plus timestamps and thread names. | | `--warning-mode` | — | (filters warnings) | Orthogonal control of deprecation/warning display. | ## When to reach for each - **`-q`** — scripting or piping Gradle output where you only care about failures, or to reduce noise in a wrapper script. - **`-i`** — the workhorse for debugging **incremental builds and the build cache**. It prints lines like `Task :compileJava UP-TO-DATE` *with the reason*, and shows input/output change detection. If a task reruns when you expected a cache hit, `-i` (or `--info`) is the first tool. - **`-d`** — last resort for deep diagnosis: plugin internals, classpath issues, full dependency graph resolution. Output is huge; usually you redirect it to a file. ## One level at a time, last wins Gradle resolves to a single active level. `gradle build -i -q` runs at QUIET because `-q` came last. Don't expect flags to combine additively. ## Not a verbosity flag: stacktrace flags `-s`/`--stacktrace` and `-S`/`--full-stacktrace` change how much of an **exception** is printed when the build fails. They are independent of the log level — you can run `gradle build -q -s` to stay quiet but still get a stacktrace on failure. ```bash gradle :app:assemble -i # see why each task is or isn't up-to-date gradle build -d > build.log # capture full debug output to a file ```

  • Which flag is most useful for diagnosing why a task wasn't UP-TO-DATE?
    `-i`/`--info` — it prints the reason a task executed or was skipped, including input/output change detection.
  • Does -d also change exception detail on failure?
    No. Exception detail is controlled by --stacktrace/--full-stacktrace, which are independent of the log level.

saying these in an interview costs you the question

  • Saying flags stack additively — only one level is active and the last flag wins.
  • Confusing -d (debug log level) with -s (stacktrace on exceptions).

context

resolving links…