# OpenHuman CI Model: CI Lite vs CI Full and Coverage Enforcement Explained

> Understand the OpenHuman CI model: compare CI Lite vs CI Full, and learn about coverage enforcement for efficient and thorough testing. Optimize your CI workflow.

- Repository: [Tiny Humans/openhuman](https://github.com/tinyhumansai/openhuman)
- Tags: deep-dive
- Published: 2026-08-29

---

**OpenHuman uses a dual-pipeline CI model where CI Lite provides rapid feedback on changed code with an 80% diff-coverage gate, while CI Full executes exhaustive cross-platform tests on every release-bound change.**

The OpenHuman project maintains code quality through a sophisticated dual-pipeline approach that balances developer velocity with release stability. Understanding the OpenHuman CI model helps contributors optimize their workflow and comprehend why certain changes trigger full test suites while others receive near-instant feedback. Both pipelines share identical Docker images and toolchain pins to ensure deterministic builds across all CI lanes.

## CI Lite: Fast Feedback for Iterative Development

CI Lite triggers on pushes to `main` and pull requests targeting `main` or `release` branches. This pipeline optimizes for speed by running tests only against modified code paths rather than the entire codebase.

For frontend changes, CI Lite executes **Vitest** unit tests exclusively for files under `app/src`. On the Rust side, it runs domain-scoped tests using `cargo llvm-cov`, limiting coverage analysis to modules that actually changed in the commit.

### The 80 Percent Diff-Coverage Gate

The pipeline enforces a strict coverage requirement using the `diff-cover` tool. It calculates coverage percentages only on lines modified in the pull request, demanding that at least **80%** of changed lines be covered by tests. This prevents coverage regressions without requiring full suite execution for every commit.

In [`.github/workflows/ci-lite.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-lite.yml), the coverage gate appears as:

```yaml

# .github/workflows/ci-lite.yml

...
- name: Run Rust coverage (changed modules only)
  run: |
    scripts/ci/rust-coverage-changed.sh
- name: Enforce diff coverage ≥ 80 %
  run: |
    ./target/debug/ci-diff-coverage --min 80
...

```

### Fallback to Full-Suite for Configuration Changes

When changes touch configuration-level files—such as [`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml), lockfiles, Vitest configuration, or top-level [`src/lib.rs`](https://github.com/tinyhumansai/openhuman/blob/main/src/lib.rs)—CI Lite recognizes the potentially systemic impact. Rather than using fast diff-coverage, it falls back to full-suite coverage scripts located at [`scripts/ci/vitest-changed-coverage.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/vitest-changed-coverage.sh) and [`scripts/ci/rust-coverage-changed.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/rust-coverage-changed.sh).

These shell scripts detect configuration modifications and automatically execute comprehensive coverage analysis across the entire codebase instead of just changed modules.

## CI Full: Exhaustive Validation for Release Readiness

CI Full activates on pull requests targeting the long-lived `release` branch and every push to that branch. Unlike the selective approach of CI Lite, this pipeline executes the complete test matrix without exception.

The pipeline runs all Vitest tests, the full Rust unit test suite, Rust mock-backend end-to-end tests, Playwright UI tests across macOS, Linux, and Windows, and the complete desktop E2E matrix. Results aggregate through the **CI Full Gate**, a mandatory check that blocks merges if any job fails. Note that Playwright specifications report as non-blocking due to inherent flakiness, though all other failures prevent merge.

From [`.github/workflows/ci-full.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-full.yml), the test matrix implementation includes:

```yaml

# .github/workflows/ci-full.yml

...
- name: Run full Vitest suite
  run: pnpm test
- name: Run full Rust test suite
  run: pnpm test:rust
- name: Playwright UI tests (macOS, Linux, Windows)
  uses: actions/setup-node@v3
  with:
    node-version: '20'
  run: pnpm e2e:playwright
...

```

## Coverage Enforcement Mechanisms

The OpenHuman CI model implements layered coverage enforcement depending on change scope. For routine code modifications, **diff-coverage** ensures new code meets quality standards without legacy coverage debt slowing development.

When configuration files change, the system invokes [`scripts/ci/vitest-changed-coverage.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/vitest-changed-coverage.sh) and [`scripts/ci/rust-coverage-changed.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/rust-coverage-changed.sh) to perform full-suite coverage analysis. This dual-mode approach guarantees that build system modifications—which could affect any part of the application—receive comprehensive validation while routine changes maintain rapid feedback loops.

Both pipelines utilize identical Docker images and pinned toolchains, eliminating "works on my machine" discrepancies between fast and full lanes.

## Key Implementation Files

- **[`.github/workflows/ci-lite.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-lite.yml)** - Defines the fast lane, changed-file test selection, and diff-coverage enforcement
- **[`.github/workflows/ci-full.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-full.yml)** - Orchestrates the complete test matrix and CI Full Gate aggregation
- **[`scripts/ci/vitest-changed-coverage.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/vitest-changed-coverage.sh)** - Handles Vitest execution for changed files with full-suite fallback detection
- **[`scripts/ci/rust-coverage-changed.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/rust-coverage-changed.sh)** - Manages Rust `cargo llvm-cov` execution for changed modules with configuration-change detection

## Summary

- CI Lite runs selective tests on `main` branch pushes and PRs, requiring 80% diff-coverage on changed lines
- Configuration changes trigger full-suite coverage scripts regardless of pipeline
- CI Full executes exhaustive cross-platform testing on `release` branch changes
- The CI Full Gate blocks merges on any failure except flaky Playwright tests
- Both pipelines share Docker images and toolchain pins for build consistency

## Frequently Asked Questions

### What triggers a full CI run instead of the fast CI Lite pipeline?

Changes to configuration-level files such as [`Cargo.toml`](https://github.com/tinyhumansai/openhuman/blob/main/Cargo.toml), lockfiles, Vitest config, or top-level [`src/lib.rs`](https://github.com/tinyhumansai/openhuman/blob/main/src/lib.rs) trigger the full-suite coverage scripts even within CI Lite. Additionally, any pull request or push targeting the `release` branch automatically runs the complete CI Full pipeline.

### How does OpenHuman prevent coverage regression without running all tests?

CI Lite uses `cargo llvm-cov` combined with the `diff-cover` tool to calculate coverage exclusively on modified lines. The pipeline enforces an 80% coverage threshold on these changed lines, ensuring new code meets quality standards without requiring full test suite execution.

### Why are Playwright tests non-blocking in CI Full?

Playwright UI tests are reported as non-blocking in the CI Full Gate because they exhibit inherent flakiness due to browser automation timing issues. However, all other test failures—including Vitest unit tests, Rust tests, and mock-backend E2E tests—will block merge completion.

### What is the difference between diff-coverage and full-suite coverage?

Diff-coverage analyzes only the lines changed in a specific commit or pull request, allowing fast feedback on incremental changes. Full-suite coverage evaluates the entire codebase, which CI Lite uses as a fallback for configuration changes and CI Full uses always, ensuring systemic modifications do not introduce regressions in distant code paths.