> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clickproof.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing pull requests

> Install the GitHub App and every pull request gets tested on a real device.

The GitHub App is how clickproof runs in CI. There is no workflow file to write
and no API key to store: install it, connect a repository to a project, and each
pull request is tested against the build your own CI already produces.

## Setup

<Steps>
  <Step title="Install the App">
    In the dashboard, go to **Integrations** and choose **Install GitHub App**.
    Pick the repositories you want it to see.
  </Step>

  <Step title="Connect a repository to a project">
    Still under **Integrations**, connect the repository to a clickproof project
    and tell it two things:

    * **Artifact name**: the name your workflow uses when it uploads the build
      with `actions/upload-artifact`. clickproof downloads that artifact from the
      pull request's own workflow run.
    * **Target branch**: only pull requests aimed at this branch run
      automatically. Leave it empty for every branch.
  </Step>

  <Step title="Open a pull request">
    Once your CI finishes and the artifact exists, clickproof picks it up, runs
    the project's tests on a real device, and reports back.
  </Step>
</Steps>

<Note>
  Your build still comes from your own pipeline. clickproof does not build your
  app; it takes the artifact your workflow already uploads, which means the thing
  under test is exactly what your CI produced.
</Note>

## What lands on the pull request

A **check run** with the verdict, and a comment with a row per test linking to
its report. A check that fails blocks the pull request the same way any other
failing check does.

Only tests whose journey touches the change are run. If a pull request changes
nothing a user can see, clickproof says so in a comment rather than silently
running nothing.

## Asking for a specific test

Comment on the pull request:

```text Run the saved suite theme={null}
@clickproof run
```

```text Run part of the suite theme={null}
@clickproof run "checkout"
```

```text Run one-off instructions theme={null}
@clickproof test: sign in with the saved account, open Settings, and confirm
the notifications toggle is off by default
```

`test:` runs exactly what you asked, once, against the current build. It is not
added to the project's suite, so a throwaway request does not come back on every
future pull request.

<Note>
  The handle is your App's slug. If you installed a self-hosted or renamed App,
  use that name instead of `@clickproof`.
</Note>

## Costs

Each test in a run counts against your plan's allowance, and an iOS run counts
double (see [Projects and tests](/essentials/projects)). If a suite would exceed
what is left, clickproof runs what fits and says on the pull request how many
were skipped, rather than failing the whole check.