bQUARKz
5984eaaf24
2.7 KiB
| id | ticket | title | created | tags | ||||
|---|---|---|---|---|---|---|---|---|
| LSN-0037 | runtime-edge-test-plan | Domain Gates Must Be Owned by the Repository | 2026-04-21 |
|
Context
PROMETEU moved runtime-edge coverage governance away from a single workspace-wide percentage and toward canonical domain gates. That shift mattered not only for policy, but also for how CI logic is expressed and maintained.
The resulting model now treats system/runtime, fs, asset/bank, firmware, and host-dependent as the operational coverage authorities for runtime-edge changes.
Key Decisions
Domain-first coverage governance
What:
The authoritative CI gate is no longer a global aggregate percentage. The gate is evaluated per canonical domain, with lines coverage compared against the domain baseline, while scenario expectations remain the real acceptance contract.
Why: A single global number can hide risk in firmware transitions, boot flow, host integration, and other sensitive edges. Domain ownership makes the gate reflect where regressions actually matter.
Trade-offs: This model is more explicit and more honest, but it requires clearer mapping between code changes, domain responsibility, and test evidence.
Repository-owned CI helpers
What:
Jenkins should call repository helpers such as make ci-domains, rather than reimplementing coverage policy inline in the pipeline file.
Why: The coverage contract evolves with the repository. When CI duplicates the decision logic, policy drifts and operational changes become harder to propagate consistently.
Trade-offs: The helper must remain readable and stable, because it becomes part of the repository contract rather than a local convenience script.
Patterns and Algorithms
- Keep the policy in repository files (
Makefile, coverage scripts, domain baseline config), and keep Jenkins as a thin caller. - Use domain-scoped baselines as a quantitative gate, but keep mandatory scenarios as the governing behavioral rule.
- Publish operationally useful coverage output that emphasizes gate status first and only exposes deeper evidence on demand.
Pitfalls
- Treating a global coverage increase as proof that a touched domain is adequately tested.
- Encoding gate math directly in Jenkins and forcing future policy changes to update multiple authorities.
- Letting verbose evidence output bury the actual pass/fail signal in CI logs.
Takeaways
- Runtime-edge coverage is safer when CI enforces domain ownership instead of trusting a workspace aggregate.
- Scenario-first review and domain baselines complement each other; neither should replace the other.
- Coverage gates that live in repository helpers are easier to evolve, audit, and keep consistent than CI-local logic.