GitHub Action

The Action measures the preview deployment a pull request produced, and writes the result back as a comment on that pull request. It lives at ritim-io/pr-review-action.

permissions:
  pull-requests: write

steps:
  - uses: ritim-io/pr-review-action@v1
    with:
      project-secret: ${{ secrets.RITIM_PROJECT_SECRET }}
      preview-url: ${{ steps.deploy.outputs.url }}

You supply two things — the project secret and the preview URL. Everything else comes from the event payload GitHub already handed the workflow.

What it does

pull_request event
  └─ read the payload            number, title, state, author, commit SHA
  └─ report it to Ritim          authenticated with psk_…
  └─ poll until the audit lands  every 3s, until done, failed, or timeout
  └─ upsert a PR comment         found by a hidden marker, edited not repeated

The comment is edited in place on subsequent runs rather than appended, so a pull request with fourteen pushes has one comment, not fourteen.

Setup

1. Create a project secret. In the dashboard, on the project, generate a secret. It looks like psk_…. Unlike the public project key this one is a credential — it authenticates a CI job that has no session.

2. Store it. Repository settings → Secrets and variables → Actions → new secret named RITIM_PROJECT_SECRET.

3. Give the job a preview URL. The Action does not deploy anything; it needs the URL of a deployment that already exists. Most hosts expose one as a step output:

- id: deploy
  uses: your/deploy-action@v1

- uses: ritim-io/pr-review-action@v1
  with:
    project-secret: ${{ secrets.RITIM_PROJECT_SECRET }}
    preview-url: ${{ steps.deploy.outputs.url }}

4. Grant pull-requests: write. Without it the audit still runs and the comment step fails.

Inputs

Input	Default	Notes
`project-secret`	—	`psk_…`. Required
`preview-url`	—	Absolute `http(s)` URL. Required
`domain`	—	Production host. Required when project >1 site
`api-url`	`https://api.ritim.io`	Staging and self-hosting
`github-token`	`${{ github.token }}`	Override only if commenting as someone else
`strategies`	`mobile`	`mobile`, `desktop`, or both
`comment`	`true`	`false` records without commenting
`wait`	`true`	`false` returns once queued
`timeout`	`180`	Seconds; clears mobile and desktop together
`fail-on-error`	`false`	Whether a failed audit fails the step

Outputs: trigger-id, status, result (the trigger document as JSON), and comment-id when a comment was written.

`domain`

The production host the pull request is work on — not the preview URL’s own host. pr-11-acme.vercel.app names a deployment, not a product, and the numbers have to be filed against the site they are a change to.

You only need it when the project has more than one site; with exactly one there is nothing to disambiguate. If it is required and missing, the API says so and the Action surfaces that message verbatim.

It is advisory by design

The rule the Action is built around: a performance report that can redden a merge is a report people delete rather than fix.

So by default nothing here fails your build. A failed audit, a preview URL that would not load, a timeout — all of them comment what happened and exit green. Two things do fail the step, because they mean the workflow is misconfigured rather than the site being slow: a missing or invalid project-secret, and a preview-url that is not an absolute http(s) URL.

fail-on-error: true opts into a stricter reading if you want it.

Limits

PR audits are capped per project per month — five on the free plan. The cap is charged per new commit, not per workflow run, so re-running a job on the same SHA does not spend another one. See Plans and limits.

What it is not

This is a synthetic audit of one deployment from one machine, not real user monitoring. It is the right tool for “did this change make the page heavier”, and the wrong one for “how fast is our site” — that question is answered by installing the SDK and real traffic.