skip to content

What does Gradle's --warning-mode flag do, and what are its possible values when you're preparing for a major-version upgrade?

level: juniorimportance: must knowfreq 55%

answer

  1. all / summary / none / fail
  2. summary is the default
  3. deprecation = preview of next major removal
  4. fail wires the guardrail into CI
  5. all + --stacktrace before a major bump

basics

~10 s

--warning-mode controls how Gradle shows warnings (mainly deprecations). Values: all, summary, none, fail. Use all to see every deprecation with details before upgrading to a new major Gradle version.

solid answer

~50 s

Gradle emits **deprecation warnings** when your build uses APIs or behaviours scheduled for removal in the next major version. `--warning-mode` decides how those surface: - `all` — print every individual warning, each with the message and (with `--stacktrace`) where it came from. - `summary` (the default in recent Gradle) — collapse to a count line at the end of the build. - `none` — suppress them entirely. - `fail` — print all warnings **and** fail the build if any deprecation occurred. When preparing to upgrade across a major boundary (e.g. 7.x → 8.0), you run with `--warning-mode all` so every deprecation that would become a hard error in the new major is visible, then fix each one. You can set it persistently with `org.gradle.warning.mode=all` in `gradle.properties`. `fail` is what you wire into CI so a new deprecation can't sneak in.

code

bash · 5 lines
bash
# Audit every deprecation before bumping the major version
./gradlew build --warning-mode all --stacktrace

# Make CI fail if any new deprecation is introduced
./gradlew check --warning-mode fail

go deeper

for a junior

Name the four values and that all shows every deprecation; know warnings preview the next major's removals.

for a middle

Explain the upgrade workflow: all to audit, fix, fail in CI; know it can be set in gradle.properties.

for a senior

Tie it to Gradle's deprecate-then-remove-at-major policy and pair it with --stacktrace to trace plugin-origin deprecations.

for a principal

Frame it as a fleet-wide upgrade governance control — fail in CI as a ratchet so deprecation debt can't grow between major bumps.

## What a deprecation warning is Gradle follows a strict deprecation policy: a feature, API, DSL element, or behaviour is first **deprecated** (it still works but logs a warning), and is only **removed** at the next **major** version bump. So the warnings you see on Gradle 8.x are a preview of what will break on Gradle 9.0. Surfacing and clearing them *before* you bump the major version is the safe upgrade path. ## The four modes `--warning-mode=<mode>` (CLI) or `org.gradle.warning.mode=<mode>` (in `gradle.properties`): - **`all`** — every warning is printed in full at the point it occurs. This is the mode you want during an upgrade audit because it shows *each* offending call, not just a count. - **`summary`** — the default. At the end of the build you get a line like `Deprecated Gradle features were used in this build, making it incompatible with Gradle N.` plus a count, but not the individual sites. It keeps normal builds quiet. - **`none`** — all warnings suppressed. Useful to de-noise an unrelated build, dangerous as a permanent upgrade strategy because you go blind to deprecations. - **`fail`** — prints all warnings like `all`, then fails the build if any deprecation was logged. This is the CI guardrail: it turns "a deprecation crept in" into a red build. ## Typical upgrade workflow ``` 1. ./gradlew build --warning-mode all --stacktrace # see every deprecation + its origin 2. fix each one (often plugin upgrades or DSL changes) 3. re-run until clean 4. bump the wrapper to the new major 5. keep --warning-mode fail in CI to stay clean ``` The `--stacktrace` flag matters because many deprecations originate inside a *plugin*, not your own build script — the stack trace tells you which plugin (and therefore which plugin upgrade) you need. ## Where the line is owned This topic is specifically the **upgrade** angle: using the modes to surface and eliminate deprecations ahead of a major-version removal. The general logging/IDE reference for the same flag lives in a separate leaf.

  • Which mode is the default, and why does that matter for upgrades?
    `summary`. It only prints a count, so individual offending call sites are hidden — you must switch to `all` to actually locate and fix each deprecation before a major upgrade.
  • How do you set the mode persistently instead of on every command?
    Add `org.gradle.warning.mode=all` (or `fail`) to the project's `gradle.properties`, or pass it via `org.gradle.warning.mode` as a system/Gradle property.

saying these in an interview costs you the question

  • Saying --warning-mode only has all/none and forgetting summary and fail.
  • Claiming none is a safe permanent upgrade strategy — it hides the very warnings you need.
  • Thinking deprecations are removed in minor releases; they are removed at the next major.

context

resolving links…