Prompt
Write a GitHub Actions workflow that runs on PRs to main:
- Installs dependencies (pnpm)
- Runs linter
- Runs tests
- Runs EAS build (dry-run)
Solution
This workflow is where your SDLC choice becomes enforceable. In a waterfall-shaped process, testing is a phase — defects surface weeks after they were written, at maximum fix cost. Running lint, tests, and a build on every PR turns quality into a merge gate: "no merge without green CI and one approving review" is a written exit criterion, not a habit, and the feedback loop shrinks from weeks to minutes.
Mechanics worth naming: pull_request targeting main (not push after merge — you want the gate before integration), pnpm caching via setup-node so the gate stays fast enough that nobody routes around it, and --non-interactive because EAS in CI authenticates via an EXPO_TOKEN secret, never a login prompt. The build uses a preview profile: it proves the app still compiles and bundles without burning a production build or store credentials on every PR.
The trade-off: full native builds per PR are slow and cost build-queue minutes. Defensible middle ground — lint and unit tests on every PR, native builds on merge to main or on a label. What's non-negotiable is that the check runs before merge.
Red flag: a pipeline that only runs after merge to main. That's not a gate, it's an alarm that rings after the intruder is inside.
Say it: "CI on pull requests is my merge gate — lint, tests, and a non-interactive preview build must pass before integration, so defects are caught in minutes, not found in a release branch."