CI & Merge Conditions
Which checks run on your PR, what actually stops a merge, and what does not.
When you open a PR, automated checks run and post a preview URL. This page explains what those checks
are, and — just as importantly — what does not stand between your PR and main.
What Runs On Every PR
| Check | Workflow file | What it does |
|---|---|---|
| PR checks | .github/workflows/pr-checks.yml | Lint, TypeScript typecheck, build affected apps, run tests if a test script exists. |
| Preview deploy | .github/workflows/pr-preview-neon.yml + deploy-reusable.yml | Creates a Neon DB branch, generates migrations if the schema changed, deploys affected apps to Railway staging, posts the preview URL as a PR comment. |
Workflows run automatically on push.
If a TypeScript error breaks the build, the check turns red — which is why you should always run
pnpm build:<your-app> locally before committing.
Nothing Blocks Your Merge
This repository has no branch protection and no ruleset. That means:
- No approval is required. You can merge your own PR.
- A red check does not stop you either. The checks are advice, not a gate.
That is a real responsibility, not a convenience. The local build before committing is the only thing that actually stops a broken change from reaching production, because nothing downstream will.
There used to be two things that looked like a gate
Both are gone, and neither ever worked:
- A workflow commented "Auto-approved" or "Developer review required" on every PR. It only posted a comment — it never recorded an approval and never blocked a merge.
- A
.github/CODEOWNERSfile assigned paths to@org/developersand@org/vibe-coders. No GitHub organization namedorgexists, so GitHub ignored every line in it.
If you ever want to know what is really enforced on a repository, ask GitHub rather than reading a workflow file:
gh api repos/<owner>/<repo>/rulesets
An empty list — or a 403 on plans where private repositories cannot use rulesets — both mean the
same thing: there is no gate.
What to Expect
- Edit app code → checks run, preview URL posted, you review the preview and merge when you are satisfied.
- Add a shared table or change
schema.md→ same, plus migrations apply to Neon main on merge. Ask someone to look at schema changes even though nothing forces you to. - Touch CI or root config → same. Be correspondingly careful; this is where a mistake affects every app.
On Merge
- Production deploys automatically for the affected app(s).
- Schema migrations apply to the Neon main database.
- The PR's Neon preview branch is deleted.
Ask Claude
Quiz
Your PR touches shared/database/prisma/schema.prisma and one of the checks is red. Can you merge it?