Skip to main content
Most Peeps projects hold their tests in Peeps and run them on Peeps’ runners. A project backed by a repository works the other way round: your repository holds the tests, and your CI runs them. Peeps reads the tests from the repository, records the runs your CI reports, analyzes failures, and sends fixes and new tests back to you as pull requests. Your repository can be on GitHub or GitLab (gitlab.com or self-managed). It can hold TypeScript Playwright tests or Python tests written with pytest-playwright.

​
What Peeps does, and what stays with you

On GitLab, Peeps opens merge requests where these pages say pull requests.

​
How it connects

Your CI job always connects out to Peeps. Peeps never connects in to your runner, so running and fixing tests against a staging environment behind a VPN or firewall works as it is. Generating a new test is the exception: Peeps explores your app from its own browser.
  • No Peeps secret in your repository. The job proves who it is with the identity token your CI issues for that one job: GitHub’s OIDC token, or a GitLab ID token. There is nothing to store or rotate.
  • You install the workflow. Peeps gives you the workflow file to commit. It never edits your workflow or CI configuration files.
  • Peeps only pushes to its own branches. Fixes and new tests go on branches named peeps/…, and reach your other branches only through a pull request you merge.
The job runs the open-source Peeps action. Its security notes list exactly what it sends to Peeps, including your test files and the Playwright report, and what Peeps can do on your runner while it works on a fix or a new test. Read them before you install it.

​
How it differs from tests hosted in Peeps

A project backed by a repository runs its tests only in your CI. Some things that work on a hosted project work differently, or not yet:
  • Editing. You change a test in your repository, not in Peeps. Steps you write in Peeps are notes for people; nothing runs them.
  • Choosing an environment. Your workflow decides where tests run, so the run dialog does not ask for an environment.
  • Schedules, incoming webhooks, deployment triggers and pull request checks can’t start runs in your CI yet. Your own CI’s triggers, such as a push or a pull request, still report every run.
  • Retrying a failed run happens in your CI, not in Peeps.
  • Healing is something you ask for on a failed run, and it arrives as a pull request.
A project is connected to a repository once, while it is empty, and stays connected to it. To move an existing project’s tests into your repository, create a new project for the repository and connect that. See Connect a repository.

​
Get started

Connect a repository

Pick the repository, where the tests live, and the branch Peeps mirrors.

Add the workflow

Commit the Peeps workflow so your CI can report runs and run what Peeps asks.

How tests sync

How Peeps finds your tests, files them in folders, and follows your branches.

Run tests in your CI

Start a run from Peeps, and see where each result shows up.

Add a test from Peeps

Describe a test in Peeps and get it back as a pull request.

Fix a failing test

Ask Peeps for a fix, verified in your CI before it opens a pull request.