Per-repo CI workflows; master matrix only owns deploys
Per-repo CI workflows; master matrix only owns deploys
Decision
Each repo (every site under sites/, every extension under
extensions/, every package under packages/) owns its own
.github/workflows/ci.yml that runs lint + typecheck + build on
every PR. The master matrix workflow at
chirag127/oriz/.github/workflows/deploy.yml no longer runs CI
gating — it now ONLY owns production deploys (matrix over every
site, deploys to its Cloudflare Pages target).
Why
The earlier "one matrix workflow runs everything" approach made PRs inside a sub-repo unable to gate themselves — the matrix only triggered on the master pointer bump. That pushed breakage into master repeatedly. Per-repo CI catches breakage at PR time, in the repo where the change actually lives, with the contributor watching the green/red mark in their own PR. Master matrix stays useful for "deploy everything when a pointer bumps" without doubling as a CI gate it can't fulfil.
Implications
- Each site/extension/package repo gets a
.github/workflows/ci.ymlwithpnpm install+ lint + typecheck + build steps. - Each extension repo also gets a cross-store publish workflow (Chrome + Firefox + Edge stores) — separate file from
ci.yml. - Master
deploy.ymlis reduced: matrix over sites, runs only on master pointer-bump commits, deploys to Cloudflare Pages. - New repos must include a CI workflow at bootstrap — adding it later means days of un-gated commits land before the first PR.
- envpact CI integration (
chirag127/envpact-action@v0) goes in each repo's CI when the build needs secrets.