Gate a pull request with b8e ci

If you want a pull request to fail when it introduces accessibility violations, run b8e ci as a build step. It scans, reports, and exits non-zero on gating findings, so your CI provider marks the check red.

Fail the build on new violations only

If you want to gate only the files a pull request changed — not the whole backlog — diff against the base branch with --base:

b8e ci --base origin/main

b8e scans the files changed since that git ref and gates on those alone. Point --base at whatever ref your CI exposes as the merge target.

Choose which findings fail the build

By default b8e ci fails on block-level findings and lets warn-level ones through. If you want warnings to fail the build too, raise the gate with --fail-on:

b8e ci --base origin/main --fail-on warn

Read the exit code

b8e ci follows the grep/eslint convention:

• 0 — nothing gated; the check passes.
• 1 — gating findings; the check fails.
• 2 or higher — the tool failed to run (a bad --base, a broken baseline, a crash).

A crash exits 2, distinct from 1, so a findings failure is never confused with the tool falling over. See the exit-codes reference for the full contract.

Wire it into a workflow

In a GitHub Actions job, let the exit code drive the check — do not swallow it:

- run: b8e ci --base origin/${{ github.base_ref }}

If you want a rollup digest in the job summary and a sticky PR comment, add --summary.

For every flag b8e ci accepts, see the ci reference.