# Get your release checklist into CI

Start with a browser test in the web app, then use the optional CLI to run repository YAML in a CI job and act on its exit code.

The pull request passes unit tests, but someone still has to open staging and check the main flow by hand.

Start with one important flow. Draft it in the web app and read the result. When it's useful, download the YAML into your repository and add a job that runs it against staging. A failure exits non-zero, and the link in the job log opens the failing step on your instance.

CI needs an environment the runner can reach and reliable test data. A gate also only helps if someone investigates failures, so decide who that is before you make the job required.

## How to do it in Zerocheck

1. Draft and run one important flow in the web app.
2. Download its YAML, add it to your repository and sign the CLI in to your instance.
3. Add a CI job that installs the CLI and Chromium, with ZEROCHECK_API and a project token. The docs include an example GitHub Actions workflow to adapt.
4. Choose blocking tests, require the job in branch protection, and read failures from the results link.

## Frequently asked questions

### Does Zerocheck block a merge?

The CLI exits non-zero for a blocking failure. Your repository's branch-protection rules must require the job.

### Do tests run entirely inside GitHub Actions?

The browser can run on your CI runner. Your instance makes the decisions and model calls, and keeps the results and screenshots.

---
Canonical: https://tryzerocheck.com/use-cases/zero-to-ci/
Updated: 2026-11-01