How do I get an HTML report out of Pylint?

Pylint emits JSON natively and `pylint-json2html` turns it into a browsable page: `pylint mypkg --output-format=json > pylint.json && pylint-json2html -f json -o pylint.html pylint.json`. Publish `pylint.html` and share the URL.

Why not just read the console output?

On a legacy codebase Pylint's first run is thousands of lines. Nobody triages that in a terminal, and pasting it into a channel destroys it. A grouped, sortable page is triageable; a wall of `C0114: Missing module docstring` is not.

Can I publish this from CI without failing the build?

Yes. Pylint's exit code is a bitmask, so pipe it through `|| true` or check specific bits, and run the publish step with `if: always()` so the report exists regardless of the gate's verdict.

Does it stay one URL as the codebase improves?

PATCH the same report id on each run. The URL is stable and every run appends a revision, which turns a lint-debt cleanup from a claim into a visible downward line.

Can reviewers claim findings?

Yes. Anchored threads sit on the specific finding, so "I'll take the `too-many-arguments` in the parsers package" is recorded on the row rather than lost in a standup.

Share a Pylint HTML report

The first time you run Pylint against an inherited Python codebase it prints several thousand lines and everybody agrees to deal with it later. Later never arrives, partly because there is no artifact to point at — just a command whose output scrolls off.

Produce the page

pip install pylint pylint-json2html

pylint mypkg --output-format=json > pylint.json || true
pylint-json2html -f json -o pylint.html pylint.json

The || true is deliberate: Pylint returns a bitmask exit code (fatal, error, warning, refactor, convention), so any finding at all makes the command "fail". You want the report either way.

Publish it

Drag pylint.html into the app, or from CI:

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 pylint.html \
        --arg title "Pylint — $(git rev-parse --short HEAD)" \
        '{title: $title, html: $html}')"

The generated page is self-contained, so there is nothing else to upload.

PATCH the same report id every run: one URL, a revision per run, and lint debt that goes down becomes a chart rather than an assertion.

Make the cleanup collaborative

A lint backlog is only ever cleared by someone claiming a slice of it. That is what the anchored threads are for:

A thread on the too-many-locals cluster in etl/ — "mine, this week".
A thread on a rule you intend to disable rather than fix, with the reason recorded next to the rule instead of in a # pylint: disable comment that says nothing about why.

See commenting on HTML.

Scheduling it

Lint reports are the natural case for a routine: re-run weekly against main, PATCH the same report, and the trend maintains itself. Nobody has to remember to regenerate anything.

Limits

Entry HTML: 5 MB. A very large first-run report can approach that — filter to errors and warnings (--disable=C,R) for the shareable view and keep the full JSON in CI.
Assets: 25 MB per file, 250 MB and 500 files total.
60 requests/minute per token.

Try it

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

Publish a lint report →