# Get your release checklist into the pull request

Start with a browser test in the web app, then use the optional CLI to run repository YAML in GitHub Actions and post a result on the pull request.

Start with a browser test in the web app, then use the optional CLI to run repository YAML in GitHub Actions and post a result on the pull request.

## Who it is for

- Role: Engineering lead or developer
- Company: Teams using GitHub Actions
- Trigger: Manual QA is slowing down merges

## Why this is underserved

- CI needs a usable test environment and reliable test data.
- A merge gate is only useful if the team can investigate a failure.
- Adding more tests helps when each one verifies behavior the team cares about.

## The workflow

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

After: A saved browser test runs against staging in GitHub Actions. One PR comment links to the full result, including the failing step when a test fails.

## How Zerocheck handles it

1. Draft and verify one important flow in the web app.
2. Download its YAML, add it to your repository and authenticate the CLI.
3. Generate a GitHub Actions workflow with zerocheck init --github-actions and configure the project token and environment.
4. Choose blocking tests, require the workflow in branch protection, and inspect failures from the PR result.

## Good fit when

- A web app and a repeatable user flow
- A test environment, test accounts and an explicit expected outcome

## Frequently asked questions

### Does a PR comment block a merge?

The CLI exits non-zero for a blocking failure. Your GitHub branch-protection rules must require the workflow; the comment itself does not gate merges.

### Do tests run entirely inside GitHub Actions?

The local browser can run on your CI runner. It still uses Zerocheck’s AI service and uploads results and artifacts to the web app.

---
Canonical: https://tryzerocheck.com/use-cases/zero-to-ci/
Updated: 2026-09-14