skip to content

What does the --problems-report console link give you, and how does it relate to the terse summary lines Gradle prints?

level: middleimportance: should knowfreq 30%

answer

  1. console = terse summary + link
  2. link -> full grouped HTML detail
  3. same data, richer view
  4. keeps CI logs short
  5. [Incubating] wording may change

basics

~10 s

Gradle prints a clickable file:// link to the aggregated problems-report.html. It connects the short console summary (like 'deprecated features were used') to the full structured detail in the HTML.

solid answer

~40 s

Gradle keeps console output terse on purpose: instead of dumping every warning, it prints a one-line summary (e.g. "Deprecated Gradle features were used in this build...") plus an `[Incubating] Problems report is available at: file://.../problems-report.html` link. The link is the bridge to the **full** structured view — the HTML report where the same problems are grouped by ProblemId, with severity, locations, details, and solutions. So the console gives you the headline and a pointer; the report gives you the body. This separation lets CI logs stay short while still preserving complete diagnostics: you click the link locally, or upload the HTML as a CI artifact and open it from the build summary. The flag/link is a *view* onto the same aggregated data the Problems API produced, not a separate report.

code

bash · 7 lines
bash
$ ./gradlew assemble

1 problem was found reporting issues.
[Incubating] Problems report is available at: file:///home/me/app/build/reports/problems/problems-report.html

# Don't grep the console string (it's incubating); rely on the file path instead:
$ test -f build/reports/problems/problems-report.html && echo 'report present'

go deeper

for a junior

Know the console prints a clickable link to the HTML report with the full details.

for a middle

Explain the summary-vs-detail split and that the link is a richer view over the same aggregated data.

for a senior

Discuss CI integration: upload the self-contained HTML as an artifact and avoid asserting on incubating console text.

for a principal

Standardize report archival across pipelines so every team has a consistent entry point into build diagnostics.

## Two layers of output: summary vs. detail Gradle deliberately splits diagnostics into two layers: 1. **Console summary** — short, human-glanceable lines such as: - `Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.` - `1 problem was found reporting issues.` These are intentionally terse so they do not bury the rest of the build output. 2. **The Problems Report HTML** — the full, structured detail, reached via the printed link: - `[Incubating] Problems report is available at: file:///.../build/reports/problems/problems-report.html` ## What the link/`--problems-report` view gives you Following the link opens the aggregated report where, for each problem, you can see: - the **group/id** it belongs to (the navigation tree), - its **severity**, - **where** it occurred (locations), - contextual **details**, and - any **solutions** the reporter attached. Crucially it is the *same data* the console summarized — the link is a richer **view**, not a different computation. That is why the summary count and the report's entries line up. ## Why this design - **Clean logs:** A build hitting one deprecation in 500 files prints one summary line, not 500 warnings. - **CI-friendly:** The single self-contained HTML is easy to upload as an artifact; reviewers open it instead of scrolling raw logs. - **Stable entry point:** Tooling can rely on the link/path being printed when problems exist. ## Practical workflow ```bash # Local: click the printed file:// link, or open it directly ./gradlew build open build/reports/problems/problems-report.html # CI: archive the report so reviewers can open it from the run # (e.g. upload build/reports/problems/ as an artifact) ``` ## Gotcha The `[Incubating]` marker reminds you the exact wording/format is still evolving across 8.x — script against the file path, not against the precise console string.

  • Why does Gradle print a one-line summary instead of every individual warning?
    To keep console and CI logs readable; the full per-occurrence detail lives in the linked HTML where it is grouped and aggregated.
  • Should CI assertions match the exact console link text?
    No — the line is marked [Incubating] and may change; assert on the file path build/reports/problems/problems-report.html instead.

saying these in an interview costs you the question

  • Claiming the link points to a different/separate report than what the summary counts.
  • Hard-coding the incubating console wording in scripts or tests.

context

resolving links…