Skip to main content

Set up PR review

Enable automated security review for pull requests on a project. Each pull request receives an AI-driven security audit with inline comments and fix suggestions.

Prerequisites​

  • An AISafe account with manager or higher role.
  • A connected repository, via GitHub or GitLab. AISafe does not review Bitbucket pull requests yet.
  • A Project bound to the repository.

You do not need to run a code audit first. Prior audit knowledge improves the context when it exists, but PR review also works on a new project.

An anonymous public repository URL is enough for a scan. PR reviews require an authorized connection to the exact repository so AISafe can receive events and publish feedback. Connected public repositories work too.

Steps​

  1. Connect GitHub or GitLab. In Integrations, connect one of them and grant access to the repositories you want to review. Ensure the connection has pull request webhook permissions for each repository you want to review.
  2. Create a project. Select a connected repository and set its branch and path scope. If your workspace may connect several repositories from one provider, use one project when they form one application and shared context helps the review.
  3. Select the reviewing project. Open PR Reviews → Settings. Each repository has its own policy. Enable reviews for the repositories this project should review, then save each policy. Within a workspace, only one project may own a repository's reviews. If another project already owns it, release that selection before choosing this project. A selection-required notice means you must choose explicitly between earlier competing configurations.
  4. Choose which events start a review. Tick the pull-request events this repository should be reviewed on: opened, updated with new commits, reopened, closed, edited, and requested in a comment. AISafe reviews on opened, updated, reopened, and comment requests unless you change it. At least one event has to stay ticked.
  5. Decide about outside contributors. Set Pull requests from people without write access. With the default setting, AISafe reviews such a pull request only when a maintainer comments @aisafe review on it, so a repository that accepts one-off pull requests from outsiders does not pay for a review of each one. Choose Review automatically to review them like any other pull request.
  6. Choose publication options. Configure branch and path filters, draft review, clean summaries, status checks, and the severity at which a check should fail. Settings apply separately to each repository.

The next matching pull request triggers a review with all companion repositories held at the same commits on the base and head sides. Each workspace runs and pays for its own review, even when another workspace reviews the same upstream PR.

Asking for a review in a comment​

Anyone with write access to the repository can start a review by commenting on the pull request:

@aisafe review

/aisafe review works too, as does mentioning the app by its own name. AISafe adds a 👀 to your comment and reviews the commit the comment was made on. If the branch moves on before the review starts, comment again on the new commit.

A comment from somebody without write access does nothing. This stops an outside contributor from spending your review allowance. The request is a plain comment, and AISafe does not read anything else in it: there are no options or arguments.

To turn off review requests in comments, untick requested in a comment in the repository's events.

GitHub repositories need the AISafe app subscribed to Issue comments, and GitLab projects need the webhook's Comments trigger enabled. Without them the comment never reaches AISafe. A repository you set up before this feature existed also needs its PR-review settings saved once, so requested in a comment is added to its events.

Required status checks​

Copy the Required check name from the repository's saved policy when setting branch protection rules. Each workspace and project has its own name. If a rule still requires the old generic AISafe check, update it to this name, because new reviews will not use the old name. Keep only the checks your team intends to require.

Verify with a test PR​

  1. Create a branch with a harmless source change in a repository you selected.
  2. Open a pull request to a branch allowed by its policy.
  3. Confirm that the check and summary identify the expected workspace and project. A clean review posts a summary when Comment on clean reviews is enabled.

If a pull request does not trigger a review, check the project's Source tab and the delivery log. See How it works for how to diagnose a missed event.

Next steps​