Skip to main content
The GitHub integration does two things. It runs your saved procedures against a pull request and reports back in one comment. It also mirrors your own check runs so you can see your CI and your QA on one timeline.

​
Setting it up

1

Install the GitHub App

Project settings → GitHub → Connect GitHub. You are taken to GitHub to install the Testorim app on the repository you want, then brought back to the same section. Install it through this button: an installation made directly on GitHub is not picked up.
2

Pick the installation and repository

Choose the GitHub installation and the Repository this project tests.
3

Choose which procedures run

Tick them under Procedures to run on each pull request. Keep it to the ones that matter on every PR. A slow suite makes people ignore the comment.
4

Tell it where previews live (optional)

Preview address pattern is where each pull request’s preview deploy lives, with {{branch}} or {{prNumber}} in it, for example https://preview-{{prNumber}}.your-app.com. Leave it blank to test the project’s own address.
5

Subscribe to check runs (optional)

To mirror your own CI, the app’s webhook subscription must include the check_run event. In GitHub: the app’s settings → Permissions & events → Subscribe to events.
Run on PRs is the master switch; turn it off to pause without losing the setup. Re-run on every push runs the procedures again when new commits land on an open pull request. Only a workspace owner or admin can link the repository or change the preview pattern, because a saved procedure’s password may be typed on the preview. Members can pick procedures and switch the link on or off.

​
What happens on a pull request

  1. When a pull request is opened or reopened (and on every push, if you chose that), Testorim builds the preview address from your pattern and uses it as the base address for the run.
  2. The selected procedures are dispatched in chunks sized to your plan’s concurrent run limit, each chunk finishing before the next starts.
  3. One comment is posted and edited in place as results arrive, not a new comment per run. While work is queued, the comment says how many are done and how many are waiting. A run that needs review is marked, and so is the headline when nothing failed.
A pull request from a fork runs only when its author is an owner, member or collaborator of the repository, so a stranger’s fork cannot run your procedures with your credentials. If the workspace is out of runs, the comment says so instead of dispatching. If it has lost access entirely, a single “Testorim is paused for this project” comment is posted and nothing runs.

​
PR activity

With check_run subscribed, Testorim keeps a read-only mirror of your repository’s check runs: lint, test, build, deploy, whatever you have.
  • The project overview shows Recent PR activity: the last pull requests with an aggregated status of in progress, success, failure or mixed.
  • /project/<project-id>/pr/<number> shows one pull request’s unified timeline: your check runs and Testorim’s QA runs together, each with its verdict, auto-refreshing while anything is in progress.
Full logs link out to GitHub; Testorim stores a truncated summary, not your build output.

​
Security

Webhook deliveries are verified by HMAC with a constant-time comparison, and each delivery is processed exactly once. A redelivery is acknowledged and does nothing.
The GitHub integration needs a subscription (a trial counts).