Skip to main content

ADR-0007 — GitHub Actions for CI/CD

  • Status: Accepted
  • Date: 2026-04-22
  • Decision-makers: Tom Anderson

Context​

We need automated test + deploy on every push. Per-shop deploys triggered by pushes to shops/{shop} branches. The bible (this site) should rebuild on every push to main.

Alternatives:

  • GitHub Actions — integrated with GitHub repos, free tier generous, good Cloudflare support via cloudflare/wrangler-action
  • CircleCI — older, more sophisticated config, paid past small free tier
  • GitLab CI — would require moving from GitHub
  • Cloudflare Pages Git integration — only handles Pages deploys, not Worker deploys; would need a second system for Workers
  • No CI, manual wrangler deploy — fine for one developer, breaks at the first team member

Decision​

GitHub Actions for all CI/CD. Workflows live in .github/workflows/:

  • test.yml — runs on every push: lint, typecheck, vitest, schema verification
  • deploy-shop.yml — runs on push to shops/* branches: deploys that shop's Worker, applies D1 migrations
  • deploy-bible.yml — runs on push to main for the bible repo: builds Docusaurus, deploys to Cloudflare Pages
  • nightly.yml — runs on schedule: full integration tests against a dev Worker

Workflows use the CLOUDFLARE_API_TOKEN and per-environment secrets stored in GitHub Actions Secrets.

Consequences​

Positive:

  • Push-to-deploy reduces ops friction; deploys are one git push
  • Per-shop branches give per-shop deploy isolation
  • PR previews on the bible give docs reviewers easy preview links
  • Cheap (free tier covers our usage; ~5 minutes per deploy)
  • One vendor for source + CI (GitHub)

Negative:

  • GitHub-as-CI vendor lock-in. Mitigation: workflows are portable; the configuration is *.yml files
  • Secrets management in GitHub Actions is fine for our scale; would prefer a dedicated secrets manager at 50+ shops
  • The wrangler-action upstream is maintained by Cloudflare; if it stagnates we'd need to vendor it

Notes​

A solo developer doesn't strictly need CI — local wrangler deploy works. CI matters when:

  • A team member joins (the workflows enforce convention)
  • A production incident requires rolling back from a known-good ref (CI gives us that ref)
  • Shops scale past the manual deploy threshold (~10 shops)

We set CI up now because it's cheap to set up and expensive to retrofit.

See also​