summary: CI job graph, scope gates, release umbrellas, and local command equivalents
title: CI pipeline
read_when:
- You need to understand why a CI job did or did not run
- You are debugging a failing GitHub Actions check
- You are coordinating a release validation run or rerun
- You are changing ClawSweeper dispatch or GitHub activity forwarding
This page is an index. CI is documented on nine pages, one per reader job. Open the page that matches your task.
For the published-upgrade regression gate, see selection and routing, runner budgets, and Package Acceptance baselines. Weekly validation is listed under Update Migration.
Docs-only main pushes skip CI. Docker seed and QA Smoke use the same owner-path selection on pull requests and main; manual CI and Full Release Validation retain their coverage. Control UI performance uses its own UI/build/import scope. See scope selection for the coverage trade-off.
Android native resource preparation uses the Mermaid renderer's filtered dependency install, including optional build tooling. Pnpm retains root dependencies but omits unrelated plugin packages; Gradle still builds the assets and runs the selected native tests and lint. Historical targets keep their compatibility path.
Short hybrid jobs use a 40-row base threshold and 45-row hosted admission limit, with unchanged coverage and Blacksmith fallback when optional work does not fit.
Real-Gateway browser checks use job budgets matched to their selected runner.
| Page | Read it when |
|---|---|
| CI pipeline jobs | The job table, the fail-fast order, and the Control UI size budgets. |
| Watch a CI run | Wait on one pull request head, recover a stuck run, and pass the evidence gate. |
| CI checkout ownership | Shared checkout anchors, fetch retry budgets, and trusted action policy. |
| CI scope and routing | Why a job did or did not run: changed-scope detection and manual dispatch. |
| CI runner classes | Trust-based runner routing, Blacksmith classes, and runner backend modes. |
| CI capacity and shard weights | The runner registration budget and the measured timings behind shard packing. |
| Release validation workflows | Full Release Validation, live and E2E shards, Package Acceptance, install smoke, Docker E2E, and Plugin Prerelease. |
| Scheduled and maintenance workflows | OpenClaw Performance, QA Lab, CodeQL, the maintenance jobs, and ClawSweeper activity forwarding. |
| Local checks and Testbox | Reproduce a lane locally, keep the shrink-only ratchets, and run Crabbox or Testbox proof. |
Where each section moved
Every section heading from the previous single-page version keeps its anchor here, so an existing link such as /ci#pipeline-overview still resolves. Each entry points at the page that now holds the content.
- Pipeline overview
- Fail-fast order
- Control UI size budgets
- Watching pull request CI
- Recover an existing PR run first
- PR context and evidence
- Checkout ownership
- Scope and routing
- Measured shard weights
- ClawSweeper activity forwarding
- Manual dispatches
- Windows Testbox Probe
- Runners
- Blacksmith runner capacity
- Runner backend modes
- Runner registration budget
- Surface ratchets
- Local equivalents
- OpenClaw Performance
- Vitest paired benchmark
- Full Release Validation
- Live and E2E shards
- Package Acceptance
- Jobs
- Candidate sources
- Suite profiles
- Legacy compatibility windows
- Examples
- Install smoke
- Local Docker E2E
- Tunables
- Reusable live/E2E workflow
- Release-path chunks
- Plugin Prerelease
- QA Lab
- CodeQL
- Security categories
- Platform-specific security shards
- Critical Quality categories
- Maintenance workflows
- Dependency Audit
- Docs Agent
- Duplicate PRs After Merge
- Local check gates and changed routing
- Config baseline count ratchet
- Testbox validation