Step 6
A manual CI runner and service-scoped quality gates
4 views
Table of contents
The important part of CI is repeatable evidence, not the product name. The example repository uses one operating-system-independent Node runner directly.
Name the service instead of running the entire monorepo blindly. With no shell-specific wrappers, every operating system uses the same command and exit code:
node tools/quality-gate.mjs web
node tools/quality-gate.mjs console
Check the current quality runner and each workspace manifest for exact arguments. Record test, typecheck, lint, and build results with the execution environment.
Layers
- fast content inventory, unit tests, and type checks
- Testcontainers integration tests with a real database
- browser smoke/E2E with writes protected
- Git-SHA image, readiness, and real DB-reading smoke
- target-only rollback with recovery evidence
Instead of hiding merge policy and alerts inside a remote CI product, make the local/operations log and release tag identify the verified commit. If remote CI is added later, it must call this Node SSOT and gain an explicit secret, artifact, and branch-protection contract.
Try it
Change one content file, run the named service gate, then inspect the PROD dry-run and smoke plan for the same commit. A failed run should show its last successful stage and how to retry.