> ## Documentation Index > Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt > Use this file to discover all available pages before exploring further. # Tests in your repository > Keep your Playwright tests in your own GitHub or GitLab repository and run them in your own CI. Peeps reads them, records every run, analyzes failures, and proposes fixes and new tests as pull requests. 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 | | Your repository and CI | Peeps | | - | - | - | | **The tests** | Live in your repository. You change them the way you change any code. | Shows each test as a read-only test case, filed in folders that match your directories. | | **Runs** | Run in a job in your CI, with your secrets, your dependencies and your network. | Starts runs in your CI when you ask, and records every run your CI reports. | | **Failures** | Show up in the runs your CI reports. | Analyzes each failure from the job's report, trace and screenshots. | | **Fixes** | You review and merge them. | Works out a fix in a job in your CI, re-runs the test there, and opens a pull request only when it passes. | | **New tests** | You review and merge them. | Writes a new test from a test case you describe, checks it passes in your CI, and opens a pull request. | 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](/repository/add-a-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](https://github.com/Peeps-Labs/peeps-action). Its [security notes](https://github.com/Peeps-Labs/peeps-action/blob/main/SECURITY.md) 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](/repository/connect). ## Get started Pick the repository, where the tests live, and the branch Peeps mirrors. Commit the Peeps workflow so your CI can report runs and run what Peeps asks. How Peeps finds your tests, files them in folders, and follows your branches. Start a run from Peeps, and see where each result shows up. Describe a test in Peeps and get it back as a pull request. Ask Peeps for a fix, verified in your CI before it opens a pull request. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.