Skip to main content
The GitHub App is how clickproof runs in CI. There is no clickproof 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 its mobile build or web preview URL.

Setup

1

Install the App

Open the project you want tested and go to its PR Testing tab, then choose Install GitHub App and pick the repositories you want it to see. You only do this once per organization; every project can then use it.
2

Connect a repository to the project

Back on PR Testing, pick the repository. Setup lives inside the project because the project is what you are connecting, so there is no project to choose again.For a mobile project, press Detect from recent builds and clickproof looks at your repository’s recent successful workflow runs, opens the artifacts they uploaded, and works out which one is an Android build and which one is an iOS build. You get a checkbox per platform it found, already ticked. Untick one to leave that platform untested.Detection is a button rather than something that happens on its own, because reading an artifact means downloading it.Target branch is optional: set it and only pull requests aimed at that branch run automatically; leave it empty for every branch.For a website project there are no artifacts to configure. Connect the repository and clickproof waits for GitHub to report a successful preview deployment from Vercel, Netlify, Cloudflare Pages, or another provider.
3

Open a pull request

Mobile projects start once CI artifacts exist. Website projects start once the preview deployment is ready. Both report back through the same Check Run and pull-request comment.
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.

Testing both platforms

If your repository builds Android and iOS, one push tests both. Each platform gets its own check run, so a green Android and a red iOS are two separate lines on the pull request rather than one combined verdict. Once connected, the platforms you ticked are stored. Nothing is re-detected when you open the page or when a pull request arrives: a push tests exactly the platforms that are on. Toggle one off on the PR Testing tab and it stops being tested from the next push, without disturbing the other.
actions/upload-artifact re-roots the zip at whatever path you give it, so uploading build/ios/iphonesimulator/Runner.app produces a zip of the bundle’s contents with the .app name lost, and there is then nothing for clickproof to recognise. Copy the bundle into a directory first and upload the directory:
If an artifact turns out to hold a different platform than the one it is configured for, clickproof posts a neutral check saying so instead of testing an Android build as if it were iOS.

Checking a connection

Test connection on the PR Testing tab checks the configured artifact names against what your workflows actually upload, and suggests the closest real name when one does not match. An artifact name typo used to surface as a pull request that quietly got no check run at all.

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:
Run the saved suite
Run part of the suite
Run one-off instructions
A mention runs on every platform that has a build on the pull request, the same as a push does. 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.
The handle is your App’s slug. If you installed a self-hosted or renamed App, use that name instead of @clickproof-ai.

Costs

Each test in a run counts against your plan’s allowance, and an iOS run counts double (see Projects and tests). Testing both platforms therefore costs both. 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.