CI Pipeline: Typecheck + Lint + Build

This document details the GitHub Actions CI pipeline for Odys, a full-stack Next.js application designed for professionals managing client bookings, payments, and communications. The pipeline ensures every change undergoes rigorous type checking, linting, and a production build before merging—critical for maintaining stability across a complex 10-table database schema and 21 API routes.

Overview

The CI pipeline is structured in two sequential jobs: check and build. The check job runs type validation via tsc --noEmit and linting with npm run lint, preventing type errors and style inconsistencies early. Only upon success does the build job proceed, executing npm run build with all required environment secrets injected—ensuring the Next.js app (using React 19.2.4 and Drizzle ORM) compiles correctly against real configuration. This separation optimizes feedback speed and avoids wasting resources on builds that won’t typecheck.

Odys operates on a rich data model with 10 tables including professionals, appointments, and recurringSchedules, all interconnected via foreign keys with cascading deletes. With API routes like /api/booking and /api/stripe/webhook handling critical workflows, and cron jobs scheduled via /api/cron/reminders, any deployment instability could disrupt user experience or data integrity. The CI pipeline acts as the first line of defense.

Design decisions

The pipeline uses ubuntu-latest and Node 20, aligning with modern runtime standards and ensuring compatibility with dependencies like @supabase@^2.100.1 and stripe@^21.0.1. Caching via actions/setup-node with cache: npm speeds up dependency installation. The build job depends on check via needs: check, enforcing a fail-fast strategy. All environment variables—such as DATABASE_URL, STRIPE_SECRET_KEY, and UPSTASH_REDIS_REST_URL—are sourced from GitHub secrets, preventing exposure while enabling a full build simulation.

Potential improvements

1. Add test execution — The pipeline currently omits running unit or integration tests, despite the presence of API routes like /api/messages and cron handlers. Adding a test job after check would improve confidence. See .github/workflows/ci.yml.

2. Parallelize lint and typecheck — The check job runs typechecking then linting sequentially. These could run in parallel using separate jobs with a shared needs: [typecheck, lint] dependency in build, reducing total CI time. See .github/workflows/ci.yml.

3. Validate environment consistency — The build injects numerous secrets, but no step verifies .env.local schema or checks for missing keys during typecheck. Introducing a script like npm run validate-env in the check job could catch misconfigurations earlier. See .github/workflows/ci.yml.

References

• .github/workflows/ci.yml — Full CI workflow definition
• schema.tables — 10-table Drizzle schema influencing build-time type safety
• apiRoutes.routes — 21 API endpoints that must remain build-stable