Development & CI/CD

The two SiteCrate-owned repos (studio-website, sitecrate-admin) share the same development loop and the same CI/CD shape. Client repos do not — they deploy via the Netlify CLI (see Client delivery).

The development loop

# Start a feature or fix
git checkout -b feature/my-change

# Make changes, then push and open a PR
git push origin feature/my-change
gh pr create --base main --title "Description" --body "What and why"

# GitHub Actions fires automatically:
#   1. Lint & Build (check) runs first
#   2. If it passes → deploy to staging + posts a PR comment with the URL
# Review on staging, then merge:
gh pr merge --squash
# Production deploys automatically after merge.

Never push directly to main

Branch protection is not enforced (it requires GitHub Pro on private repos), so this is self-enforced. Always branch, open a PR, and let CI run. npm run lint must pass with zero errors before merging.

The two workflows

Both repos have two workflow files in .github/workflows/:

File	Trigger	What it does
pr.yml	Every PR to main (opened / updated / reopened)	Two sequential jobs: check (lint + build) must pass, then deploy-staging deploys to staging and posts a PR comment. Rapid pushes cancel the in-progress run via a concurrency group.
deploy-prod.yml	Push to main (after merge)	Builds with prod env vars → deploys to production.

Why two sequential jobs in one file

Using needs: check inside pr.yml makes the staging deploy depend on lint + build passing. Separate workflow files cannot depend on each other — they always run in parallel, which would deploy broken code to staging even when CI fails. One file, two jobs, needs: check between them.

GitHub secrets

Configured per repo in GitHub → Settings → Secrets. Values are not shown here — this is the map of what each job consumes.

studio-website

Secret	Used in	Purpose
NETLIFY_AUTH_TOKEN	both workflows	Netlify personal access token
NETLIFY_SITE_ID	deploy-prod.yml	Production Netlify site
NETLIFY_SITE_ID_STAGING	pr.yml	Staging Netlify site
VITE_SUPABASE_URL	all	Supabase project URL (same for prod & staging)
VITE_SUPABASE_ANON_KEY	all	Supabase anon key (same for prod & staging)
VITE_SUPABASE_SCHEMA_STAGING	pr.yml deploy-staging job	Value staging — routes the staging app to the isolated schema

sitecrate-admin

Everything above, plus:

Secret	Used in	Purpose
SUPABASE_SERVICE_ROLE_KEY	pr.yml, deploy-prod.yml	Server-side only (admin-users.js) — never VITE_-prefixed

Why staging needs an explicit schema, prod doesn’t

VITE_SUPABASE_SCHEMA is not passed to deploy-prod.yml. Production falls back to 'public' via the || 'public' default in supabase.js. Only the staging job sets VITE_SUPABASE_SCHEMA=staging. That single variable is the entire mechanism that isolates staging data from prod.

Local function testing

Vite’s npm run dev does not run Netlify functions. To test send-email (or any function) locally, use:

netlify dev   # local dev with Netlify functions wired up

See Environments & credentials for the full env-var map, and Email for the send-email function specifics.