CI Checks on PRs

The Hook (The "Byte-Sized" Intro)

CI checks on PRs are the bouncers at the merge door. You want in? Pass the tests. Pass the linter. Pass the security scan. Fail any one, and the merge button stays grey. This is how teams ship clean code without relying on humans to catch every mistake — the machine does it first.

📖 What is CI Checks on PRs?

CI checks are automated tests and validations that run on every pull request. They're configured as required checks, meaning a PR cannot be merged until all checks pass.

Conceptual Clarity

Common CI checks:

Check	What It Does	Why
Tests	Runs unit/integration tests	Catches regressions
Linter	Checks code style	Enforces consistency
Type check	Validates types (TypeScript, etc.)	Catches type errors
Security scan	Scans for vulnerabilities	Prevents security issues
Build	Verifies the project compiles	Catches build breaks
Coverage	Reports test coverage %	Prevents coverage drops

Check statuses:

Status	Meaning	Merge Allowed?
✅ Passed	All checks green	✅ Yes
❌ Failed	One or more checks failed	❌ No
🟡 Pending	Checks still running	❌ Not yet
⏭️ Skipped	Check not triggered	✅ (if not required)

Real-Life Analogy

CI checks are like a preflight inspection. Pilots don't just decide the plane "looks fine" — there's a mandatory checklist. If any item fails, the plane doesn't take off. No exceptions.

Visual Architecture

flowchart LR PR["🔀 Pull Request"] --> CHECKS["🔧 CI Checks"] CHECKS --> TESTS["✅ Tests"] CHECKS --> LINT["✅ Linter"] CHECKS --> BUILD["✅ Build"] CHECKS --> SEC["✅ Security"] TESTS & LINT & BUILD & SEC --> MERGE["🟢 Merge Enabled"] style PR fill:#1a1a2e,stroke:#53d8fb,color:#53d8fb style MERGE fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Quality gate: Prevents broken code from reaching main.
Automation: Catches issues machines are better at finding than humans.
Confidence: Reviewers focus on logic, not style or syntax.
Consistency: Every PR goes through the same validation.

Code

yaml

# ─── GitHub Actions: CI on PRs ───
name: CI
on:
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run lint
      - run: npm run build

bash

# ─── Set required checks (GitHub CLI) ───
# In repo Settings → Branches → Branch protection rules:
# ✅ Require status checks to pass before merging
# ✅ Require branches to be up to date

# ─── View check status on a PR ───
gh pr checks 42
# Shows: ✅ test, ✅ lint, ❌ build

Key Takeaways

CI checks run automatically on every PR — no manual triggering needed.
Required checks block merging until they pass.
Common checks: tests, lint, build, security, coverage.
Reviewers focus on design and logic; CI handles everything else.

Interview Prep

Q: What are required status checks and why are they important? A: Required status checks are CI jobs that must pass before a PR can be merged. They act as automated quality gates, preventing broken code from reaching the main branch regardless of manual review.
Q: What is the benefit of running CI on pull requests vs only on main? A: Running on PRs catches issues before they reach main, when they're easier to fix. Issues caught on main would require a revert or hotfix and affect the entire team.
Q: How do CI checks complement code review? A: CI handles mechanical checks (tests passing, lint compliance, build success) while human reviewers focus on design, logic, and maintainability. Together they provide comprehensive quality assurance.