Does Psalm write HTML?

No. `--report=FILE` picks the format from the extension — `.sarif`, `.junit.xml`, `.checkstyle.xml`, `.json`, `.txt` and a few more. HTML comes from rendering the SARIF.

Which output should I render?

SARIF. It preserves the issue type, severity and the exact code region, which is what makes the rendered page usable as a triage surface rather than a list.

How do I handle the baseline?

Run the report with the same `--baseline` your gate uses. The published page then shows only what the baseline does not already accept, which is the actionable set.

Can I show the Psalm level going up?

Yes — PATCH one report id per repo. Moving from level 4 to level 3 becomes a diff between two revisions of the same URL.

Should the report step be the gate?

No. Suffix it with `|| true` and keep a separate unmuted `psalm` step, so a rendering failure never masquerades as an analysis failure.

Share a Psalm report

Psalm's error levels run from 1 (strictest) to 8, and almost every real codebase is sitting somewhere in the middle with a baseline file holding back the tide. Tightening that is a team activity, and team activities need an artifact everyone can point at.

Psalm writes plenty of formats. HTML isn't one of them — but SARIF is, and SARIF renders.

SARIF → HTML

composer require --dev vimeo/psalm
pip install sarif-tools

./vendor/bin/psalm --report=psalm.sarif --no-cache || true
sarif html psalm.sarif --output psalm.html

SARIF keeps the issue type (PossiblyNullReference, MixedArgument), the severity and the file region, so the rendered page groups the way a human would triage it.

Publish it

Drag psalm.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 psalm.html \
        --arg title "Psalm — $GITHUB_REF_NAME" '{title: $title, html: $html}')"

Keep ./vendor/bin/psalm as its own unmuted step if you want the build to fail on new issues.

The baseline is the story

psalm --set-baseline=psalm-baseline.xml is how most projects adopt Psalm: freeze the existing issues, fail on new ones. That works, and it also makes the debt invisible — nothing in the daily run mentions the thousand entries sitting in the baseline file.

Publish a second report without --baseline on a schedule and you get the number back:

A routine re-runs it weekly and PATCHes the same id, so the real total is a URL rather than a guess.
Anchored threads on a cluster — "these forty are all the same untyped array shape in the legacy mailer" — so the cleanup can be claimed in slices. See commenting on HTML.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total. An unbaselined first run on a large app is the one that gets close — scope it to a directory for the shareable view.
60 requests/minute per token.

Try it

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

Publish a static analysis report →