skip to content

How would you make the Problems Report useful in CI, and what makes it well-suited (or not) to that role?

level: seniorimportance: should knowfreq 25%

answer

  1. single self-contained file -> easy artifact
  2. grouped -> scales to many warnings
  3. absent == clean, not failed upload
  4. root project build dir only
  5. report describes, doesn't enforce

basics

~10 s

Archive build/reports/problems/problems-report.html as a CI artifact so reviewers open one self-contained page instead of scrolling logs. It is well-suited because the file is single, self-contained, and grouped.

solid answer

~50 s

Because the report is a **single, self-contained HTML file** keyed by ProblemId groups, it is ideal as a CI artifact: configure the pipeline to upload `build/reports/problems/problems-report.html` (and the `problems/` dir) on every run, then link it from the build summary. Reviewers open one grouped page instead of grepping logs, and because identical problems aggregate, even a build with thousands of warning occurrences yields a scannable document. The main limits to plan around: it is only written when problems exist (so a missing file means clean, not failed upload), it lives in the **root** project's build dir, and the console link text is `[Incubating]` so don't gate on it. For a deprecation-burndown program, archiving it per run lets teams diff problem counts over time before a major Gradle upgrade. It is *not* a replacement for failing the build — pair it with `--warning-mode fail` or explicit checks when you want enforcement, using the report for triage.

code

bash · 9 lines
bash
# Archive the report; tolerate its absence (no problems == clean build)
REPORT=build/reports/problems/problems-report.html
if [ -f "$REPORT" ]; then
  cp -r build/reports/problems/ "$CI_ARTIFACT_DIR/"
  echo "Problems report archived"
else
  echo "No problems reported this build"
fi
# Enforcement is separate: e.g. ./gradlew build --warning-mode fail

go deeper

for a junior

Know you can upload the HTML as a CI artifact to read diagnostics later.

for a middle

Explain why single+self-contained+grouped makes it a good artifact and that absence means a clean build.

for a senior

Design the upload (tolerate absence, archive root path) and separate description from enforcement via --warning-mode fail.

for a principal

Drive an org deprecation-burndown program: archive per run, track stable ProblemIds over time, and standardize artifact wiring across pipelines.

## Why the report fits CI well Three properties make the Problems Report a natural CI artifact: 1. **Single file** — `build/reports/problems/problems-report.html`. One path to archive. 2. **Self-contained** — styles/data inlined, so it opens correctly from an artifact store with no broken assets. 3. **Grouped/aggregated by ProblemId** — thousands of occurrences collapse to a navigable tree, so the artifact stays useful at scale. ## A concrete CI strategy ```yaml # pseudo-CI steps: - run: ./gradlew build continue-on-error: true # capture diagnostics even on failure - uploadArtifact: name: problems-report path: build/reports/problems/ # the whole dir, in case of extra assets ifNoFilesFound: ignore # absent == no problems this run ``` Then surface a link to the artifact from the run summary so reviewers click straight into it. ## Things to design around - **Generated only when problems exist.** A missing file is the *clean* case, not a failed upload — set `ifNoFilesFound: ignore`/equivalent so you don't fail green builds. - **Root project only.** In a multi-project build the report is under the **root** `build/reports/problems/`, not per subproject — archive that one path. - **Incubating console string.** Don't assert on the printed link wording; rely on the file path. - **Not an enforcement gate.** The report *describes* problems; it does not *fail* the build. If you want enforcement, combine it with `--warning-mode fail` (for deprecations) or explicit verification tasks, and use the report for human triage. ## Burndown over time Because ProblemIds are stable, archiving the report every run lets you track counts per id across builds — a practical way to drive deprecation cleanup ahead of a major Gradle upgrade (e.g. preparing 8.x → 9.0). You can even parse the underlying problem events via the Tooling API for dashboards, treating the HTML as the human view and the events as the machine view. ## Anti-patterns - Uploading per-subproject build dirs hoping to find the report — only the root has it. - Treating the report's presence as a build failure signal. - Hard-coding the incubating link text into pass/fail logic.

  • If the report file is missing in CI, what does that most likely mean?
    That the build reported zero problems — the report is only written when problems exist, so absence is the clean case, not a failed upload.
  • How do you turn the report from triage into enforcement?
    Pair it with mechanisms that actually fail the build, like --warning-mode fail for deprecations or explicit verification tasks; the report itself only describes problems.
  • In a multi-project build, which build dir holds the report?
    The root project's build/reports/problems/ — it aggregates across all projects, so you don't archive per subproject.

saying these in an interview costs you the question

  • Treating a missing report as a CI failure rather than a clean build.
  • Expecting per-subproject reports in a multi-project build.
  • Believing the report fails the build by itself.

context

resolving links…