skip to content

When would you apply `project-report`/`build-dashboard` versus relying on the built-in `dependencies`/`tasks` tasks or external tooling?

level: seniorimportance: nice to knowfreq 22%

answer

  1. console = interactive/one-off
  2. project-report = persisted + aggregated HTML
  3. build-dashboard = single index of report kinds
  4. build scans = hosted cross-build analytics
  5. reporting tasks cost resolution time

basics

~10 s

Use the built-in dependencies/tasks tasks for quick interactive console checks. Apply project-report/build-dashboard when you need persisted, browsable, aggregated HTML reports for CI archival or a single index across reports.

solid answer

~40 s

The choice is interactive-vs-archival and single-vs-aggregated. The always-available `dependencies`, `tasks`, and `properties` tasks print to the console — perfect for a developer poking at one project. The `project-report` plugin persists the same information as files (and an HTML dependency report that aggregates subprojects), which you want when CI should publish reports as artifacts or when reviewers need a browsable, searchable dependency view across a multi-project build. `build-dashboard` adds a single HTML index over all `Reporting` tasks that ran, so reviewers have one entry point to tests, coverage, static analysis, and dependency reports. For large orgs, external tooling like Develocity build scans often supersedes these — providing richer, hosted, cross-build dependency and performance insight — so the core reporting plugins are most valuable when you want zero external dependencies and self-hosted HTML artifacts.

go deeper

for a junior

Know the difference between console tasks and persisted HTML reports.

for a middle

Explain when aggregation (htmlDependencyReport, buildDashboard) beats per-project console tasks.

for a senior

Weigh CI archival, build-time cost, and wiring buildDashboard into the right invocation.

for a principal

Decide org-wide between self-hosted reporting plugins and a hosted build-scan/Develocity strategy, factoring history, governance, and cost.

## The decision axes 1. **Interactive vs. archival.** Built-in `dependencies`/`tasks`/`properties` print to the console — ideal for a developer at a terminal, useless for storing. Reporting plugins write files you can archive. 2. **Single vs. aggregated.** Console tasks are per-project and per-kind. `htmlDependencyReport` aggregates subprojects; `buildDashboard` aggregates report *kinds* into one index. 3. **Self-hosted vs. external service.** Core reporting plugins are bundled and produce local HTML. Build scans (Develocity) are a hosted/extension service with far richer cross-build analytics. ## When to use the built-ins - Quick local debugging: `./gradlew :app:dependencies --configuration runtimeClasspath`. - One-off `dependencyInsight` to explain a version. No plugin needed. ## When to apply project-report - You want a **browsable, searchable** dependency view, especially across many subprojects. - CI should **publish** dependency/task/property reports as artifacts for later inspection. ## When to apply build-dashboard - A build emits many report kinds (tests, coverage, static analysis, dependencies) and you want **one link** to hand to reviewers. - Note: it only links reports for tasks that **ran**, so wire it into the same invocation (e.g. `./gradlew check buildDashboard`). ## When to prefer external tooling - **Develocity build scans** give hosted, shareable, cross-build dependency, performance, and failure analytics, plus historical trends — beyond what static HTML can offer. At org scale this often replaces the core reporting plugins. ## A pragmatic combination ```bash ./gradlew check htmlDependencyReport buildDashboard # CI archives build/reports/** and links buildDashboard/index.html ``` This yields self-contained HTML covering everything that ran, with no external service. ## Trade-offs - Reporting tasks **resolve** configurations and run extra work, adding build time — run them in CI report stages, not on every developer build. - Static HTML lacks history/search-across-builds; if you need that, invest in build scans.

  • Why not run reporting tasks on every local developer build?
    They resolve configurations and do extra work, adding build time. Reserve them for CI report stages or on-demand; developers can use the cheaper console tasks interactively.
  • What does a build scan offer that build-dashboard does not?
    Hosted, shareable, cross-build history and analytics (performance, dependency, failure trends) rather than a single static HTML snapshot of one invocation.

saying these in an interview costs you the question

  • Claiming project-report replaces the need for build scans for org-wide analytics.
  • Forgetting buildDashboard only links reports for tasks that executed.
  • Treating reporting tasks as free — they trigger resolution and extra work.

context

resolving links…