Pull Request Checks

What it does #

A pull request check analyses only the files your pull request changes, compares what it finds against the lines you actually touched, and posts the result as a single comment on the pull request.

Two things make it different from a normal scan:

  • It’s scoped to your diff. A 12-file pull request in a 5,000-file repository analyses 12 files. That’s why it finishes in minutes rather than taking as long as a full scan.
  • It’s kept separate from your repository’s results. Findings from a pull request check never enter your repository’s issue list, and they never move your Production Ready Score. A pull request can’t dent your score, and merging one can’t silently improve it either.

When you’d use it #

Use it to catch problems while they’re still cheap to fix β€” during review, on the code you just wrote, instead of after the merge when the finding shows up in a full scan alongside everything else.

How to use it #

There’s nothing to set up. Once the GitHub App is installed on a repository:

  1. Open a pull request against the repository’s default branch (usually main).
  2. Norma checks the changed files. This takes minutes, proportional to the size of your diff.
  3. Norma posts one comment with the results.
  4. Push a fix. The check re-runs and the comment is replaced with fresh results.

What the comment looks like #

The comment is headed Norma β€” Pull Request check and leads with the issues your changes introduced, most severe first:

Norma β€” Pull Request check #

8 issues introduced by this Pull Request:

  • πŸ”΄ High Β· Security Β· src/lib/auth.ts:23 β€” AI Provider API Key in Source Code

    How to fix: Move ALL AI API calls to Supabase Edge Functions. Store the key as an Edge Function secret. The frontend calls your Edge Function, which proxies the request to the AI provider.

  • 🟑 Medium Β· Manageability Β· src/lib/auth.ts:98 β€” TypeScript any Type Usage

    How to fix: Replace any with the concrete type, or unknown plus a narrowing check when the shape is genuinely dynamic.

  • 🟑 Medium Β· Manageability Β· src/lib/auth.ts:207 β€” TypeScript any Type Usage

For context: 3 pre-existing issues already in the files you touched (not introduced by this Pull Request).

View the full report in Norma

This check analyses only the files changed by this pull request.

Reading a line: the emoji and severity (πŸ”΄ High, 🟑 Medium, 🟒 Low) let you judge the mix at a glance, then the impact area (Security, Performance, Scalability, Manageability), then file and line, then the rule that fired.

How to fix is the rule’s remediation advice. It appears once per rule β€” when the same rule fires three times, those three hits are listed together and only the first carries the advice. A rule with no remediation advice recorded simply has no How to fix line.

View the full report in Norma opens that repository’s page in the portal. It’s the way into everything the comment doesn’t show β€” your full issue list, coverage, rulesets and score.

Introduced vs pre-existing #

Norma analyses whole files (rules need the surrounding code to judge correctly) but reports at line level:

  • Introduced by this pull request β€” the issue sits on a line your diff changed. These are the ones the comment lists.
  • Pre-existing β€” the issue is elsewhere in a file you touched. These appear only as the aggregate note at the bottom, never as your fault.

An issue caused by your change but reported on a line you didn’t touch counts as pre-existing. That’s a deliberate simplification, and it errs towards not blaming you.

When you push new commits #

Every push to the pull request’s branch re-runs the check. Norma deletes the previous comment and posts a new one rather than editing in place, so reviewers get a fresh notification for the new results. A pull request therefore carries at most one Norma comment at any moment.

Push several times in quick succession and the checks collapse into one: only the latest commit gets results, and results for a commit that’s already been superseded are thrown away rather than posted.

Other messages you might see #

Situation What Norma posts
Your changes introduced nothing βœ… No issues introduced by your changes. β€” plus the pre-existing context note and the portal link. Every pull request gets a comment.
More than 10 issues introduced The total, and the 10 most severe listed: “showing the 10 most severe”. The rest are in the portal.
Some analysis didn’t finish ⚠️ Some analysis tools did not complete, so these results may be incomplete. Results are posted anyway.
The check failed ⚠️ The analysis could not be completed for this pull request. Please try again by pushing a new commit.
Nothing applies to your stack ⚠️ This pull request was not analysed. No agent applies to this repository’s detected stack, so no code was checked. Pushing another commit won’t change this β€” the repository has no applicable ruleset. Check its stack profile in the portal.

Limits & notes #

  • Pull request checks consume no scan quota. On any tier, however many pull requests you open. Your weekly scan allowance is untouched.
  • Your Production Ready Score is never affected β€” not by a check, and not by merging a pull request that had open findings. Only full scans move the score.
  • Checks never block a merge. They’re informative: a comment, not a required status check. Norma will not stop you merging.
  • Only pull requests targeting the default branch are checked. A pull request into any other branch is ignored silently β€” no check, no comment. If you need standing quality history on another branch, scan it directly: see Scanning multiple branches.
  • Change the default branch on GitHub and it takes effect immediately for pull requests that receive pushes from then on. Comments already posted are left as they are.
  • Pull requests from forks are ignored in this release.
  • Whole-repository rulesets don’t run on a pull request check. Anything that has to see the entire codebase to reach a verdict β€” the Architecture / SOLID Analyzer, for instance β€” is excluded by design, because it can’t be judged from a diff. It still runs on your full scans. See AI Findings.
  • One check per repository at a time. Pull requests opened while another check is running on the same repository queue up and are processed in order. Different repositories run independently, and a check never interferes with a scan you launch in the portal.
  • Reopening or editing a pull request doesn’t trigger a check. Only opening it and pushing new commits do.
  • Close or merge before the check finishes and the result is discarded β€” no comment arrives.
  • GitHub only. Bitbucket repositories are scanned normally in the portal but don’t get pull request comments in this release.

Related #

Was it helpful ?