CI/CD

The problem

A starter without tests is one you're afraid to change. A pipeline that runs everything on every commit is one people learn to ignore.

What Bones does

Every pull request runs GitHub Actions, with jobs in parallel:

• Lint and format — oxlint, Prettier, and syncpack for dependency versions.
• Generated files — migrations, the auth schema, email tokens, and brand assets must match their sources.
• Backend tests — Vitest against a real, throwaway Postgres.
• Storybook tests — every component and page story, in real Chromium.
• Builds — the web app, marketing site, blog, and docs. The builds are the typecheck.
• Accessibility — the sweep described in Accessibility.
• Security — Semgrep, ZAP, the CSP check, and the secrets check described in Security.

It stays fast:

• Only what changed. Each job runs when its files, or a workspace it imports, changed. A docs change doesn't start Postgres.
• Drafts run nothing. A draft is work in progress, so CI waits until it's marked ready and then runs everything.
• A new push cancels the old run on the same pull request.
• Dependencies are cached. node_modules and Playwright's Chromium are restored from cache, and main keeps the cache warm.

Each build is kept for three days, so you can download what a pull request produced.

What isn't done yet

• CD. Nothing deploys on merge, because there's no deploy target yet. Hosting is decided — see AWS — but there's no infrastructure code.
• The desktop app isn't built in CI. A Tauri build needs Rust and system libraries, which is its own workflow.
• Nothing blocks a merge. Checks run, but branch protection isn't turned on.

How it compares

Most starters ship a lint script and an empty test folder. Bones ships a suite that already covers auth, permissions, organizations, and storage, so the first thing you add has something to lean on.

Go deeper

• GitHub Actions — why the pipeline is built this way.
• CI/CD — the jobs, and how to add one.
• Testing — running the tests yourself.