06.4 CI and monorepos
Frozen lock validation, matrix builds per member, and reproducible workspace CI."
CI and monorepos
CI for monorepos is where “works on my machine” goes to die publicly. Good.
Lock discipline
Section titled “Lock discipline”Run lock / fetch in CI with --frozen (or project-equivalent flags) so manifest drift fails the pipeline instead of production.
Commit per-project Project.lock files (and workspace-level lock artifacts if your layout uses them—follow lockfile guide).
Matrix strategy
Section titled “Matrix strategy”| Approach | Pros | Cons |
|---|---|---|
| One job per member | Clear failures | More CI minutes |
| Single job builds all | Cheaper | Harder to see who broke |
| Affected detection | Fast at scale | Needs tooling investment |
Start simple: build App + run Test target for each member you ship.
flowchart TD CI[CI pipeline] --> L[lock/fetch --frozen] L --> B1[build member A] L --> B2[build member B] B1 --> T1[test member A]
Path deps in CI
Section titled “Path deps in CI”Checkout must include all member folders referenced by relative paths. Shallow clones that omit libs/ are a classic self-own.
Website / superrepo note
Section titled “Website / superrepo note”The Beskid superrepo itself is an aggregate of submodules—your application monorepo is a smaller cousin. Same lesson: pin tool versions (beskid --version in logs).