CI Pipelines

CI (Continuous Integration) pipelines automatically verify the health of a project each time code is pushed or a pull request is opened.
In our practicum, CI pipelines run code quality checks, compile source code, and run automated tests before changes can be merged.

This page explains how CI pipelines work in our organization, and how they may differ across repos.

---

What CI Pipelines Do

View CI Pipeline Overview

A CI pipeline ensures that changes do not break the project by:

✔ Validating Code Quality

• Linting (ESLint/Prettier)
• Type-checking
• Static analysis

✔ Compiling Code

• TypeScript builds
• App builds (Next.js/NestJS)

✔ Running Tests

• Unit tests
• Coverage reports

✔ Producing Artifacts

• Compiled builds
• Coverage HTML reports

CI ensures every student, across every quarter, pushes working code, not just code that “works on their machine.”

---

How CI Runs in Our Organization

View Org-Wide CI Expectations

The practicum uses GitHub Actions for all CI workflows.

CI Should Run On:

• 💡 Pull requests — before code is reviewed or merged
• 🚀 Push to main or release branches
• 🧪 Optionally nightly or scheduled builds

Tools Commonly Used in CI:

Tool	Purpose
ESLint	Find code errors / enforces standards
Prettier	Auto-formatting
TypeScript	Catch type errors & invalid code
Jest	Run frontend/backend tests
Coverage Scripts	Validate test quality
Cache Actions	Speed up installs

CI Should Validate Before CD (Deployment)

CI pipelines must succeed before code can be deployed.
(Deployment guidelines are in the CD page.)

Not all repos fully implement this yet — standards exist so students build toward it.

---

Example: CI Pipelines in NSC Events (Monorepo)

View Example: NSC Events CI

The NSC Events repository contains two separate apps:

• nsc-events-nextjs → Frontend (Next.js)
• nsc-events-nestjs → Backend (NestJS)

This repo uses multiple CI workflows:

Workflow	Runs On	Responsibility
backend-ci.yml	push to main	Lint, compile, test backend
frontend-ci.yml	push to main	Lint, compile, test frontend
on-pull-request.yml	PR checks	Runs backend or frontend checks selectively

Selective CI: Only Test What Changed

File excerpt (paths-filter triggering):

- uses: dorny/paths-filter@v2
  id: filter
  with:
    filters: |
      frontend:
        - 'nsc-events-nextjs/**'
      backend:
        - 'nsc-events-nestjs/**'

If a PR modifies only the frontend, only frontend tests run.
This speeds up CI significantly on large monorepos.

📝 Important Note

Husky is NOT a standard across the org right now
It exists only in NSC Events to enforce CI rules locally.
Other projects do not currently include local CI simulation.

---

Structure of a Standard CI Pipeline (Template)

View Generic CI Template

Any practicum repo can structure CI like this:

name: CI Pipeline

on:
  pull_request:
  push:
    branches: [ main, develop ]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 1) Install dependencies
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci

      # 2) Lint and Type Check
      - run: npm run lint
      - run: npm run compile

      # 3) Run Tests (Optional per repo)
      - run: npm run test --if-present

      # 4) Build App
      - run: npm run build --if-present

🏗️ Students Can Copy & Modify This Template

Any new project can:

• Add coverage requirements
• Archive test reports
• Add deploy steps when ready

---

Differences Across Repositories

View Repository Comparison

✔ NSC Events (Advanced)

• Monorepo with selective CI
• Separate frontend & backend jobs
• Coverage artifacts stored
• Husky for local CI simulation

✔ Some Projects (Intermediate)

• Run tests + lint on PR
• Build on push to main

✔ Smaller Student Repos (Basic)

• Only lint + build checks

🚫 Some Repos (Legacy / Student-Owned)

• No CI yet — encourage using the template
• These should eventually adopt lint + test + build pipelines

Goal of the Practicum

Standardize all repos over time to a minimum CI requirement.