Step 6
A manual CI runner and service-scoped quality gates
0 views
Table of contents
The important part of CI is repeatable evidence, not the product name. The example repository does not use GitHub Actions as the CI SSOT. One Node runner owns the meaning, with Windows, macOS, and Linux wrappers for shell syntax.
frontend-ci.mjs
▲
├─ frontend-ci.ps1
├─ frontend-ci.bat
└─ frontend-ci.sh
Wrappers translate shell syntax and delegate service selection, commands, and exit codes to Node. Name the service instead of running the entire monorepo blindly:
node infra/scripts/frontend-ci.mjs web
node infra/scripts/frontend-ci.mjs admin
node infra/scripts/frontend-ci.mjs --help
Check the current infra/scripts and each workspace package.json 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.