# OpenHuman Two-Lane CI Model: How Pull Request Validation Works

> Explore OpenHuman's two-lane CI model for efficient pull request validation. Understand how CI Lite and CI Full ensure code quality and smooth releases for the tinyhumansai/openhuman repository.

- Repository: [Tiny Humans/openhuman](https://github.com/tinyhumansai/openhuman)
- Tags: how-to-guide
- Published: 2026-08-28

---

**OpenHuman implements a dual-pipeline continuous integration strategy where CI Lite provides rapid feedback on changed code for main branch development, while CI Full executes exhaustive cross-platform testing for any code targeting the release branch.**

The OpenHuman repository uses a sophisticated two-lane CI model to balance development velocity with release stability. This architecture, documented in [`AGENTS.md`](https://github.com/tinyhumansai/openhuman/blob/main/AGENTS.md) and implemented across [`.github/workflows/ci-lite.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-lite.yml) and [`.github/workflows/ci-full.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-full.yml), separates lightweight differential testing from comprehensive product validation. Understanding how these pipelines interact with branch targeting logic is essential for contributors submitting pull requests.

## CI Lite: Fast Feedback for Development

CI Lite serves as the rapid validation layer for day-to-day development, executing targeted checks that avoid redundant computation.

### Trigger Conditions

According to [`.github/workflows/ci-lite.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-lite.yml), this pipeline activates on every push to the `main` branch and every pull request targeting either `main` or `release`. This broad trigger coverage ensures that proposed changes receive immediate feedback regardless of their ultimate merge destination.

### Changed-Only Testing Strategy

The pipeline relies on differential testing scripts to minimize execution time. When a contributor opens a PR, the system invokes [`scripts/ci/vitest-changed-coverage.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/vitest-changed-coverage.sh) to run Vitest exclusively on modified frontend files, while [`scripts/ci/rust-coverage-changed.sh`](https://github.com/tinyhumansai/openhuman/blob/main/scripts/ci/rust-coverage-changed.sh) executes `cargo llvm-cov` only against altered Rust crates. This ensures that a frontend-only change skips unnecessary Rust compilation, and vice versa, providing results in minutes rather than hours.

## CI Full: Comprehensive Release Validation

CI Full represents the exhaustive safety net required for production-ready code, enforcing strict quality gates before software reaches users.

### Trigger Conditions and Merge Blocking

Defined in [`.github/workflows/ci-full.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-full.yml), this lane executes on every push to the long-lived `release` branch and any pull request specifically targeting `release`. The workflow implements a **CI Full Gate** check that explicitly blocks merging if any job in the matrix fails, preventing unstable binaries from shipping to end users.

### Cross-Platform Desktop Testing

Unlike the lightweight lane, CI Full validates the entire Tauri desktop application across Linux, macOS, and Windows environments. The pipeline executes the complete Vitest suite, full Rust test coverage, Playwright UI automation tests, and native desktop integration tests. To optimize resource usage, the system employs a **build-once-then-fan-out** strategy: a single compilation job produces OS-specific artifacts that downstream E2E jobs download rather than rebuilding from source.

## PR Handling Logic by Target Branch

The repository’s branch protection rules leverage the two-lane model to enforce appropriate validation depth based on the merge destination.

- **Target `main`**: Pull requests undergo CI Lite validation only. The system tests solely the modified components using the changed-coverage scripts, providing rapid iteration cycles for feature development.
- **Target `release`**: Pull requests trigger CI Full execution. Regardless of the change scope or size, the entire product surface undergoes validation, including cross-platform desktop packaging and end-to-end scenarios.
- **Promotion Path**: When maintainers trigger [`promote-main-to-release.yml`](https://github.com/tinyhumansai/openhuman/blob/main/promote-main-to-release.yml) to merge `main` into `release`, the resulting push automatically invokes CI Full to verify the consolidated state before production deployment.

## Feature Forwarding Validation

During CI Full execution, the `scripts/ci/check-feature-forwarding.mjs` utility verifies that product-gate features correctly propagate to the Tauri desktop shell. This script ensures conditional compilation flags and feature toggles remain consistent between the web frontend and backend, preventing runtime mismatches in shipped binaries that could bypass intended functionality gates.

## Code Examples

The following workflow configurations illustrate the trigger differentiation between the two lanes:

```yaml

# .github/workflows/ci-lite.yml – runs on pushes/PRs to main

name: CI Lite
on:
  push:
    branches: [main]
  pull_request:
    branches: [main, release]
jobs:
  changed-tests:
    runs-on: ubuntu‑latest
    steps:
      - uses: actions/checkout@v3
      - name: Run changed Vitest tests
        run: scripts/ci/vitest‑changed‑coverage.sh
      - name: Run changed Rust coverage
        run: scripts/ci/rust‑coverage‑changed.sh

```

```yaml

# .github/workflows/ci-full.yml – runs on pushes/PRs to release

name: CI Full
on:
  push:
    branches: [release]
  pull_request:
    branches: [release]
jobs:
  full-test:
    runs-on: ubuntu‑latest
    steps:
      - uses: actions/checkout@v3
      - name: Run full Vitest suite
        run: pnpm test
      - name: Run full Rust test suite
        run: pnpm test:rust
      - name: Run Playwright UI tests
        run: pnpm test:playwright
      - name: CI Full Gate (blocks merge on failure)
        if: failure()
        run: exit 1

```

## Summary

- **CI Lite** provides rapid differential testing on pushes and PRs to `main`, using [`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 validate only modified code.
- **CI Full** enforces exhaustive validation on the `release` branch and PRs targeting it, including cross-platform desktop builds and Playwright E2E tests gated by the CI Full Gate check.
- The [`promote-main-to-release.yml`](https://github.com/tinyhumansai/openhuman/blob/main/promote-main-to-release.yml) workflow triggers CI Full during branch promotion to ensure merged code meets production standards.
- Build optimization uses artifact sharing to avoid redundant Tauri compilation across the desktop test matrix.
- The `scripts/ci/check-feature-forwarding.mjs` script validates feature flag consistency between frontend and desktop shell during full integration testing.

## Frequently Asked Questions

### What triggers CI Lite versus CI Full in OpenHuman?

CI Lite triggers on pushes to `main` and pull requests targeting `main` or `release`, running only tests for changed files. CI Full triggers exclusively on pushes to `release` and pull requests specifically targeting the `release` branch, executing the complete test suite regardless of change scope.

### How does OpenHuman optimize desktop build times in CI Full?

The pipeline implements a build-once-then-fan-out strategy where a single job compiles the Tauri application for each operating system, uploads the resulting artifacts, and allows downstream E2E jobs to download these pre-built binaries rather than recompiling from source.

### Why does a PR to the release branch require full testing even for small changes?

Since the `release` branch represents production-ready code, the CI Full Gate mandate ensures that every modification undergoes cross-platform validation, desktop integration testing, and feature-forwarding verification to prevent regressions in shipped applications.

### Where is the two-lane CI model documented in the repository?

The architecture is documented in [`AGENTS.md`](https://github.com/tinyhumansai/openhuman/blob/main/AGENTS.md) under the "Two-lane CI model" section, with implementation details residing in [`.github/workflows/ci-lite.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-lite.yml) and [`.github/workflows/ci-full.yml`](https://github.com/tinyhumansai/openhuman/blob/main/.github/workflows/ci-full.yml), and supporting scripts located in `scripts/ci/`.