Introducing pull request reviews

Until now, MDL Shield reviewed code after the fact: a release on the Marketplace, or a branch you pointed us at. Pull request reviews move the review to the moment the code is actually decided. Install the MDL Shield GitHub App on a repository and every pull request gets a security review before it merges, with the results posted straight to the PR and to your dashboard.

The reviewer is the same one behind every MDL Shield review: an AI Moodle security specialist that reads your change the way a human reviewer would, understanding what the code does and how it fits into Moodle, not just pattern-matching lines. It is not a linter and it does not replace moodle-plugin-ci.

On the pull request

Three things land on the PR:

• A check called MDL Shield review that passes or fails according to the severity you choose to block on.
• One summary comment that always shows the current state: every finding, its severity, and its status.
• An inline comment on the exact line for each finding, with the description up front and the depth (context, risk assessment, suggested fix) folded away until you want it.

Findings in pre-existing code that your change interacts with are reported too. On public repositories those never appear on the PR, only in your dashboard, so a review can't hand a bystander a map of unfixed code.

Findings follow the code

Every push is reviewed, and findings are never re-reported push after push: a finding stays open until a commit actually fixes it, and when one does, the review resolves it and names the commit. If a later commit turns a latent risk into a real one, the finding escalates, with the evidence.

Triage from the PR

Every finding's inline thread takes commands from the repository owner and the users you trust. Reply on the finding to triage it, with a reason if you have one:

!mdlshield accept Only course managers can reach the export page

dismiss, accept, confirm and resolve are the verbs. The bot acknowledges with a thumbs up, appends the decision to the finding (who, and why), and the check recomputes. !mdlshield review on the PR forces a re-review, and so does the Re-run button on the check.

Settings in the repository, or on the site

A .mdlshield/config.yml on your default branch controls which pull requests are reviewed and how: branch, label, author and path filters, the severity that fails the check, what the check does when a review errors, who may issue commands, and the Moodle version to review against.

fail_on:
  severity: high        # the check fails on high and critical
on-error: open          # an errored review never blocks a merge

moodle:
  versions: ["5.0"]

trusted_users: ["alexc"]

include:
  branches: ["main", "MOODLE_*_STABLE"]
exclude:
  paths: ["lang/**", "vendor/**"]
  authors: ["dependabot[bot]"]

The same settings exist on the site, as account defaults and per-repository settings, so you don't need a file at all. When there is one, it wins, key by key. You can also give the reviewer private context about your plugin (what it is for, who can reach it, known trust boundaries) that guides every review and is never committed to your repository.

Your dashboard

The new Pull Requests tab lists every PR across your repositories with its open findings and check state at a glance.

Every pull request gets a page in your dashboard with the full history of review passes, every finding in full depth, and triage buttons that twin the commands. This is the only place a finding's proof of concept ever appears: it is never posted to GitHub. You can also authorise other people to view and triage without giving them settings or billing.