skip to content

What does the Gradle --warning-mode flag do, and what values can it take?

level: juniorimportance: must knowfreq 55%

answer

  1. all / summary / none / fail
  2. summary is default
  3. fail = build error on warning
  4. org.gradle.warning.mode property
  5. re-run with --warning-mode all

basics

~10 s

--warning-mode controls how Gradle reports deprecation and other warnings on the console. Values are all, summary, none, and fail. Default is summary.

solid answer

~30 s

`--warning-mode` is a command-line option that controls how Gradle surfaces warnings (chiefly deprecation warnings) during a build. It accepts four values: **all** prints every warning with its source location; **summary** (the default) suppresses individual warnings and prints a one-line count at the end pointing you to re-run with `--warning-mode all`; **none** silences warnings entirely; **fail** prints all warnings *and* fails the build if any warning is emitted. You typically use `all` locally to diagnose what's deprecated, and `fail` in CI to gate against new deprecations creeping in. The same behaviour is configurable persistently via the `org.gradle.warning.mode` property in `gradle.properties`.

code

bash · 8 lines
bash
# See every deprecation with source location
./gradlew assemble --warning-mode all

# Default behaviour: just a summary footer
./gradlew assemble --warning-mode summary

# Fail the build if any deprecation is used (CI gate)
./gradlew assemble --warning-mode fail

go deeper

for a junior

Name the four values and that summary is the default; know all is for diagnosing.

for a middle

Explain fail-mode as a CI gate and the org.gradle.warning.mode property as the persistent form.

for a senior

Discuss precedence (CLI over gradle.properties) and integrating fail-mode into the pipeline strategy.

for a principal

Frame warning-mode as part of an org-wide upgrade-readiness policy keeping every build deprecation-clean ahead of major bumps.

## What warnings are As Gradle evolves between major versions, APIs and behaviours get **deprecated** before removal. When your build script, a plugin, or Gradle itself uses a deprecated feature, Gradle emits a *deprecation warning*. These warnings are your early-warning system for the next major upgrade — code that triggers them today will break tomorrow. ## The flag `--warning-mode <mode>` controls how those warnings appear: - **`all`** — every warning is printed in full, including the deprecation message and (often) the line that triggered it. Use this when investigating. - **`summary`** — the default. Individual warnings are hidden; instead you get a terse footer like `Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.` plus a hint to re-run with `--warning-mode all`. - **`none`** — total silence. No warnings, no summary line. - **`fail`** — behaves like `all` but additionally **fails the build** the moment any warning is produced. This turns deprecations into hard errors. ## Persistent configuration You rarely want to type the flag every time. Set it once in `gradle.properties`: ``` org.gradle.warning.mode=all ``` The command-line flag overrides the property for a single invocation. Precedence (highest first): CLI flag → project `gradle.properties` → `GRADLE_USER_HOME/gradle.properties`. ## Why it matters Deprecation warnings are the single best predictor of upgrade pain. A team that runs `--warning-mode fail` in CI keeps the build deprecation-clean continuously, so the eventual major-version bump is a non-event rather than a multi-week migration. ```bash ./gradlew build --warning-mode all # diagnose ./gradlew build --warning-mode fail # gate in CI ```

  • Which mode is the default and what does it print?
    summary — it hides individual warnings and prints a one-line footer noting deprecated features were used, hinting to re-run with --warning-mode all.
  • How would you make the setting permanent for everyone on the team?
    Add org.gradle.warning.mode=all (or fail) to the project's gradle.properties, which is checked into version control.

saying these in an interview costs you the question

  • Claiming the default is 'all' — it is 'summary'.
  • Saying 'fail' only prints warnings without failing the build — it does fail.

context