Test every pull request with the GitHub App

Install the appCopy Anchor Link

In Outqube, open Settings, GitHub (organisation admins only) and select Connect GitHub. On GitHub, pick the account, choose all repositories or only some, and install. GitHub asks you to authorise Outqube CI once to prove the installation is yours. Outqube does not keep that authorisation.

GitHub sends you back to Settings, GitHub. The installation is linked to your Outqube organisation. One installation belongs to one organisation.

If you are a member but not an owner of the GitHub organisation, GitHub sends an install request to its owners. Connect again once an owner approves it.

Link a repositoryCopy Anchor Link

Select Link next to a repository. Its page opens with the app, suite and URL already picked where Outqube can tell, and a What will happen summary that says what will run and when. Check the app and suite, then under When to test choose:

• On every pull request push (the default) to test the same URL, such as your staging site, on every push.
• When a preview deploy is ready if your host creates a preview per pull request, such as Vercel or Netlify. Outqube runs the suite when the deployment of the pull request's commit succeeds, on the deployment's URL. The Preview environment name is Preview unless your host reports another.
• Only when my CI runs the Outqube CLI if your own CI starts the runs. The page shows the workflow to add.

To test only some pull requests, open More options and turn on Only test pull requests with a label. Pull requests run only once they have the label (outqube unless you pick another), and adding it starts a run. Target branches narrows them to pull requests into the branches you pick.

Select Link repository. You stay on the page, which links to GitHub to open a pull request.

Open a pull requestCopy Anchor Link

Open a pull request in the linked repository. The Outqube check goes from queued to in progress, then to a result:

Details opens the run in Outqube. The check summary has the counts and the failure reports of up to five failed tests. The comment is rewritten when the newest run is queued and when it ends. It never adds one per push.

Follow a failure backCopy Anchor Link

From a failed check, open the run, then the failed test. Each failure has a report with the failing step, the steps to reproduce and the console errors and failed requests near it, plus a screenshot. To fix it with an agent, hand the run to your coding agent through the MCP server.

To run the same tests again on the same commit, select Re-run on the check. It starts a new run linked to the old one.

Make the check requiredCopy Anchor Link

1. Open a pull request in the linked repository once, so GitHub knows the check.
2. On GitHub, open the repository's Settings, Rules, Rulesets, New branch ruleset. For classic rules, use Settings, Branches, Add branch protection rule.
3. Target your default branch and turn on Require status checks to pass. Select Add checks, type Outqube and pick it, with the source set to the Outqube CI app.
4. Save.

Pull requests can then not merge until the check passes. A failed test blocks the merge. A run that errored ends neutral, which GitHub counts as passing, so look at neutral checks when you review.