Documentation

Run your browser tests on pull requests

Read as Markdown

Use GitHub Actions to run the tests saved in your repository at the pull request's commit. Zerocheck returns an exit code, writes reports and can update a pull request comment with the results.

Prepare a saved test suite

Complete the CLI quickstart, including review and saving. Configure an environment the CI browser can reach, usually staging, in zerocheck.yaml. Add the referenced test credentials and ZEROCHECK_TOKEN as secrets in your CI setup.

Generate the starter workflow:

npx zerocheck init --github-actions

Review the generated .github/workflows/zerocheck.yml before committing it. It includes pull-request and manual triggers, a pinned CLI install, local browser installation where needed, JSON and JUnit output, result reporting and artifact upload. Environment and runner are explicit choices; ensure the selected URL and credentials are available in your job.

Read the workflow result

The underlying run and reporting commands are:

npx zerocheck run --env staging --json .zerocheck/latest-run.json --junit .zerocheck/junit.xml
npx zerocheck report --file .zerocheck/latest-run.json

Reporting and artifact upload should run even when the test command fails. The generated workflow handles this with if: always().

With the required GitHub token and pull-request permissions, reporting posts or updates one comment with outcomes, failed steps and links to evidence. The job summary remains available when a comment cannot be posted, including restricted or read-only jobs. Older commit results do not overwrite a newer comment.

Choose your merge policy

A failed blocking test exits nonzero. To prevent merging on that failure, configure the workflow check as required in your repository's branch protection or ruleset. A PR comment alone does not enforce a merge policy.

Tests default to blocks_merge: true. A test with blocks_merge: false still shows its failure but does not fail the run's merge policy. Add --fail-on-flaky if a blocking test that passed after a transient retry should also fail the workflow.

Scheduling and browser location

The generated workflow includes a commented schedule you can enable and adapt. Scheduled runs use the environment you configure. Zerocheck reports those test runs; it is not an incident-monitoring or alerting service.

Use the local runner for addresses reachable from your CI runner, or the hosted runner for addresses reachable from the Zerocheck instance. Test selection is explicit by file path; it is not inferred from a code diff.

Result interpretation · Credentials and data · GitHub integration overview

Try your own customer flow.

Free seven-day assisted evaluation. No credit card.

Try for free