Add build step to CI

[bcw117]

Features and Changes

Adds a Build GitHub Actions workflow (.github/workflows/build.yml) that runs pnpm build on every pull request and on pushes to main.

Until now the only CI we had was the Prettier/Lint workflow, which means a PR could be merged with code that doesn't compile — formatting was checked, but nothing ever verified that the Next.js app actually builds. This closes that gap so build breakages are caught in review instead of at deploy time.

Details worth calling out:

• Environment mirrors the Lint workflow. Same actions/checkout@v4, pnpm/action-setup@v4.0.0 pinned to pnpm 10.14.0, so both workflows stay in sync. Adds actions/setup-node@v4 on Node 20 with cache: pnpm to keep installs fast.
• pnpm install --frozen-lockfile instead of a bare pnpm install, so CI fails loudly if pnpm-lock.yaml is out of date rather than silently resolving something different from what we committed.
• Placeholder env vars. pnpm build runs prisma generate && next build, and several modules construct their clients (Prisma, Supabase, Mailgun, Notion) at import time. Those clients need the variables to be present and well-formed — a malformed DATABASE_URL fails Prisma's URL parsing, for example — so the job defines dummy values. Nothing in this list is a real credential and no external service is contacted during the build; the comment in the file says as much so nobody mistakes them for secrets that need rotating.
• Concurrency group on github.ref with cancel-in-progress: true, so pushing several commits to a PR in quick succession cancels the stale builds instead of queueing them all.

Screenshots / Screen Recordings

N/A — CI-only change, no UI surface.

Testing your changes

The workflow triggers on pull_request, so opening this PR is itself the test: the Build / Next.js build check on this PR is the first real run, and it needs to go green before this merges.

Steps on how to test your changes

1. Look at the Checks tab on this PR and confirm Build / Next.js build passes.
2. To confirm it actually catches breakage, push a commit to this branch that introduces a type error or a bad import, and verify the check goes red — then revert it.
3. To reproduce the CI environment locally, export the same placeholder values listed in build.yml and run pnpm install --frozen-lockfile && pnpm build.

Other Notes

• The build is not yet a required status check — that has to be configured in the repo's branch protection settings for main before it can actually block a merge. Worth doing as a follow-up, otherwise this is advisory only.
• Only the build is covered here. Type checking beyond what next build does, pnpm lint (ESLint), and tests are not wired into CI. The existing Lint workflow only runs Prettier. Those are natural follow-ups but felt out of scope for a first build step.
• The placeholder env vars are duplicated inline in the workflow. If the app grows more import-time clients, this list has to be updated by hand or the build will start failing for reasons unrelated to the PR being tested. If that becomes annoying we could move to a committed .env.ci file instead.
• Node is pinned to 20 here. If we want to match whatever the deploy target runs, happy to bump it — just let me know what that is.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
lp-website	Ignored		Aug 2, 2026 5:15am

[Copilot]

Pull request overview

This PR adds a dedicated GitHub Actions CI workflow to verify the Next.js application builds successfully, closing the gap where CI previously only enforced formatting.

Changes:

• Introduces a new Build workflow that runs on pull_request and pushes to main.
• Runs pnpm install --frozen-lockfile followed by pnpm build (with placeholder env vars) to catch build breakages during review.
• Adds workflow-level concurrency to cancel stale builds for the same ref.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.