skip to content

What does the `build-dashboard` plugin do, and how does the `buildDashboard` task discover which reports to include?

level: middleimportance: should knowfreq 40%

answer

  1. single buildDashboard task
  2. HTML index of all reports
  3. discovers Reporting-interface tasks
  4. only tasks that actually ran
  5. build/reports/buildDashboard/index.html

basics

~10 s

build-dashboard adds a buildDashboard task that generates a single HTML index linking to every report-producing task that runs in the same build invocation (tests, dependency reports, etc.).

solid answer

~30 s

The core `build-dashboard` plugin contributes one task, `buildDashboard`, which produces a single HTML landing page that aggregates links to all the reports generated during a build. It discovers reports by inspecting tasks that implement Gradle's `Reporting` interface (i.e. expose a `reports` container) and that actually execute in the invocation — for example test results, JaCoCo coverage, checkstyle/PMD, and `project-report`'s dependency reports. You wire it by running the report tasks together with `buildDashboard`, e.g. `./gradlew test buildDashboard`; the dashboard only links reports for tasks that ran. The index lands at `build/reports/buildDashboard/index.html`, giving one entry point to everything.

code

bash · 3 lines
bash
# build-dashboard aggregates reports from tasks that RAN in this invocation
./gradlew check buildDashboard
# open build/reports/buildDashboard/index.html

go deeper

for a junior

Know it makes one HTML index linking to the build's reports.

for a middle

Explain the Reporting-interface discovery and that only executed report tasks are linked, hence run them together.

for a senior

Discuss composing it with project-report, test, coverage and static-analysis tasks, and output relocation via ReportingExtension.

for a principal

Treat it as a build-observability entry point and decide whether a dashboard or external tooling (build scans) is the right org standard.

## The problem it solves A real build emits many reports — JUnit results, coverage, static analysis, dependency reports — each in its own directory. `build-dashboard` provides a single HTML index that links to all of them so you don't have to remember paths. ## Applying it ```kotlin plugins { id("build-dashboard") } ``` It adds exactly one task: **`buildDashboard`**. ## How discovery works — the `Reporting` interface Gradle tasks that produce reports implement the `org.gradle.api.reporting.Reporting<T>` interface and expose a `reports` container (e.g. `Test`, `JacocoReport`, `Checkstyle`, `HtmlDependencyReportTask`). The `buildDashboard` task scans the task graph for tasks implementing `Reporting` and collects the report locations they declare. Crucially, it only includes reports from tasks **that actually executed in the same invocation**. So discovery is dynamic, not declarative — the dashboard reflects what you asked Gradle to do. ## Wiring it in practice Because discovery is execution-based, you run the report tasks alongside `buildDashboard`: ```bash ./gradlew check buildDashboard # or ./gradlew test htmlDependencyReport buildDashboard ``` If you run `buildDashboard` alone, the index is nearly empty because no report tasks ran. ## Output The dashboard HTML is written to `build/reports/buildDashboard/index.html` (respecting the `ReportingExtension` base directory). Each linked report is the report task's own output directory. ## Relationship to project-report `project-report` *produces* dependency/task/property reports; `build-dashboard` *aggregates links* to those (and any other `Reporting` task's) reports. They compose: apply both, run their tasks together, and the dashboard links the project reports too. ## Gotchas - Reports only appear if their task ran — common surprise when `buildDashboard` is invoked in isolation. - It links existing report outputs; it does not re-run or regenerate them. - In multi-project builds you typically apply it where you aggregate, and run with the relevant report tasks across projects.

  • Why might buildDashboard produce an almost-empty index?
    Because it only links reports for tasks that executed in the same invocation. Running buildDashboard alone means no report-producing tasks ran, so there is nothing to link.
  • How does the task know which reports exist?
    It scans the executed task graph for tasks implementing the Reporting interface (those with a `reports` container) and collects their declared report destinations.
  • Does build-dashboard regenerate the reports it links?
    No — it only links existing outputs of report tasks that ran; it does not re-execute or recreate them.

saying these in an interview costs you the question

  • Saying buildDashboard generates the reports itself — it only aggregates links.
  • Believing it statically lists every possible report regardless of execution.
  • Confusing it with project-report (which produces dependency/task/property reports).

context

resolving links…