Getting started

Warpway reviews pull requests in the GitHub repositories you choose. For each pull request it plans a review, investigates the change through lenses such as Correctness and Security, and asks people only the questions it cannot resolve. Results appear as one check, Warpway / Review, and one summary comment on the pull request.

This guide takes you from nothing to your first review. Nothing blocks a merge until you decide it should.

Before you start

• A GitHub account that can install GitHub Apps on the organization or personal account that owns your repositories. In a GitHub organization, an organization owner installs the app because it requires Members read access. Repository admins and other members can request installation for an owner to approve.
• Optional, on the Team plan: a Slack workspace where you can install apps, so Warpway can ask product, legal or operations experts questions in Slack.

1. Sign in with GitHub

Go to Sign in and choose Continue with GitHub. Warpway has no passwords: your GitHub account is your identity. Signing in identifies you and the GitHub installations you can access. It does not install anything or give Warpway access to new repositories.

2. Install the GitHub App

Choose Install on GitHub, pick the organization or account, and choose All repositories or Only select repositories. You can change the selection on GitHub at any time. GitHub installation walks through the options, and GitHub permissions lists exactly what the app can and cannot do.

When the installation completes, GitHub returns you to Warpway, first asking you to authorize it if you have not signed in before. Warpway creates your organization from the GitHub account you installed it on and makes you its first Owner. One GitHub account maps to one Warpway organization.

3. Review the repository analysis

Warpway reads the default branch of each enabled repository and detects:

• languages, package managers, test frameworks and build configuration;
• a CODEOWNERS file;
• CI workflows and the checks they report;
• security and architecture documents;
• an existing .warpway.yml and whether it is valid;
• database migrations and public API definitions.

From that it recommends lenses. Correctness, Security and Testing / Reliability are required on every pull request. Backward Compatibility, Product Semantics and Database Safety are required when a change touches what they cover. Architecture / Maintainability and Performance run as advisory lenses that warn but do not block. Accept the recommendation or adjust it; see Lenses.

4. Connect Slack (optional)

On the Team plan an Admin can connect Slack. Questions about product behavior, billing rules or policy then reach the people who can answer them in a direct message, with buttons for the expected answers. See Slack installation.

5. Open a pull request

Open a pull request in an enabled repository, push a commit to an open one, or mark a draft as ready for review. Draft pull requests are skipped unless you set review.include_drafts to true.

On the pull request you will see:

• the Warpway / Review check on the head commit: in progress while the review runs, then a result for every lens and whether your review policy is satisfied;
• one summary comment listing what was cleared, which decisions are open and who was asked, any findings, and the policy status. Warpway edits this comment in place as the review progresses instead of posting new ones;
• line annotations on the check, only for concrete findings;
• review requests for engineers who were asked a question, when your organization allows them.

6. Decide how much Warpway may do

New repositories start at trust level 1, Assist: Warpway routes questions but its check never blocks a merge. When you are ready:

• on the Team plan, raise the repository to Gate and make Warpway / Review a required check, so a pull request cannot merge until your policy is satisfied. On the Free plan the trust level is capped at Assist. See Merge gating;
• on the Team plan, add a .warpway.yml to version your review policy with your code. See Configuration as code;
• read Trust levels before going beyond Gate.

What you do not need

• Changes to your CI. Warpway reads the results your CI already reports as GitHub checks. Runtime verification is optional.
• Accounts for Slack-only experts. People who only answer questions do so in Slack.
• A configuration file. The defaults work out of the box; .warpway.yml is there when you want it, on the Team plan.

Next steps

• How reviews work: what happens between the webhook and the check.
• Human tasks: how questions are asked, answered and checked.
• Troubleshooting: if a check does not appear.