How do I get an HTML report out of ktlint?

The CLI takes `--reporter=html,output=build/reports/ktlint.html`, and the Gradle plugin exposes the same reporters through the `ktlint { reporters { reporter ReporterType.HTML } }` block. Either way you get one self-contained file.

Where does the Gradle plugin write it?

Under `build/reports/ktlint/` — one file per source set, e.g. `ktlintMainSourceSetCheck.html`. Publish the one for the source set people care about, or publish each as its own report.

Can I publish when the check fails?

Yes, and that is the interesting run. Use `--continue` on the Gradle invocation, or `|| true` around the CLI call, then publish before the job exits.

Should ktlint findings block the build?

For formatting, no — run `ktlintFormat` and commit. For rules that are genuine style decisions, publishing a report and letting the team argue on it beats a gate nobody agreed to.

Can teammates comment on a rule?

Yes. Threads anchor to the rendered content, so the reasoning behind a `.editorconfig` change stays attached to the violations that motivated it.

Share a ktlint HTML report

ktlint is opinionated on purpose, and that is why it needs a report. A tool that just formats needs no discussion; a tool that enforces opinions generates one, and the discussion always happens away from the evidence — in a channel, in a PR comment thread, in a meeting where somebody is describing what the build output said.

ktlint --reporter=html,output=build/reports/ktlint.html

Or through Gradle, which is where most Kotlin projects run it:

// build.gradle.kts
ktlint {
    reporters {
        reporter(ReporterType.HTML)
    }
}

./gradlew ktlintCheck --continue
# → build/reports/ktlint/ktlintMainSourceSetCheck.html

--continue matters: without it the first failing source set ends the build and the later reports are never written.

Publish the file

Drag the HTML into Comma — it is self-contained, so there is no folder to zip. Or publish from CI and keep one permanent URL:

./gradlew ktlintCheck --continue || true

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html build/reports/ktlint/ktlintMainSourceSetCheck.html \
        --arg t "ktlint — $(git rev-parse --short HEAD)" '{title: $t, html: $html}')"

See the API reference and publishing from CI.

Format automatically, publish what is left

The split that keeps a Kotlin codebase calm:

ktlintFormat in a pre-commit hook. Whitespace, import order and trailing commas are not worth anyone's attention, and a machine settles them.
Publish a report for the rest. Rules like function-naming, max-line-length and the experimental set are genuine choices, and a link full of real examples is a much better basis for making them than an abstract argument about style.

Anchored comments put each decision on the violations that caused it — "these are all generated DTOs, adding them to .editorconfig excludes" — and they survive republishes. See commenting on HTML.

Multi-module projects

A Gradle multi-module build writes a report per module per source set, which is a directory of files nobody will open individually. Two workable shapes:

One report per module, PATCHed from that module's job, so each team has a URL that is theirs.
One aggregate report — merge the HTML bodies, or publish the root module's file and attach the rest as assets on the same report, which keeps them at one link. See report assets.

Who can see it

Per report: private, your team, anyone signed in at your domain, or anyone with the link. See sharing & access control.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total.
Scripts run, sandboxed — no same-origin access.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a lint report →