INTRO
CI exists to catch “works on my machine” before merge. For Next apps, the critical path is usually: lint + `tsc --noEmit` + `next build` (which also validates many config mistakes). Tests come next once the team agrees they will not flake.
Workflow skeleton
Trigger on `pull_request` to main. Use `actions/setup-node` with `cache: npm` (or pnpm/yarn). Matrix Node version only if you support multiple runtimes.
Fail fast: run lint and typecheck before build to save minutes.
code-snippet.yaml
jobs:
ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm run lint
- run: npx tsc --noEmit
- run: npm test --if-present
- run: npm run buildSecrets and fork PRs
GitHub does not expose secrets to workflows from forks by default - good. Document that external contributors need maintainers to run CI.
Use environment-scoped secrets for deploy jobs, not global repo secrets when possible.
Add E2E when the product stabilizes
Playwright against preview deployments catches regressions UI tests miss, but flakiness costs trust. Start CI with build correctness; add E2E for critical flows (checkout, signup) incrementally.
KEY TAKEAWAYS
“Cache deps; order checks from fastest signal to slowest.”
- 02
Require `tsc` and `next build` for type + config safety.
- 03
Treat fork PR secret rules as a feature, not annoyance.
CONCLUSION
Closing thought
Good CI is short and reliable. Start with lint, types, and build - then grow tests as the codebase earns them. Ready to talk scope? Use Contact — or browse Services for fit.
CONTINUE
Related pages
UP NEXT
React Accessibility for Dashboards and Forms
Concrete patterns: associate labels, announce async errors, and make data tables navigable without breaking layout.
Read next article