CI Pipelines

The purpose of CI is to answer one question as fast and as truthfully as possible: is this change safe to merge? Every design decision — stage order, what runs in parallel, what blocks merge — should be judged against that question. A pipeline that is fast but lies (flaky, non-deterministic, skips real checks) is worse than no pipeline, because people stop trusting it and start merging past red.

A pipeline that takes twenty minutes but never lies beats one that takes two minutes and is wrong once a week.

A CI pipeline exists to produce a merge signal that is fast, deterministic, and trusted — in that order of what you sacrifice first.

For concrete GitHub Actions patterns — caching, matrix builds, SHA pinning, OIDC, reusable workflows — read references/github-actions.md.

1. Order stages cheapest-and-most-likely-to-fail first