Repository navigation
evidence(OMN-14454): contract for the omnibase_infra DoD-runner canary - #4027
Conversation
Separate from OMN-14436's contract because of a constraint that only became visible once check_values actually began executing: A contract belongs to a TICKET, but its check_values run in whatever REPO cites it. OMN-14436's contract is OCC-specific (pytest/mypy/ruff over OCC paths) and BLOCKs when run with cwd = the infra tree -- which is exactly what the canary makes happen. A cross-repo ticket cannot have one contract that passes in both repos. Every check here is a gh api CONTENT READ and therefore workspace-INDEPENDENT -- it observes the product no matter which tree the runner is pointed at. That is the same property that makes OMN-14418/OMN-14409 the known-good control group for this canary. Three product-observing checks on omnibase_infra#2267: runner actually invoked (not the dead validate-yaml) contract-compliance in NO needs: list (a BLOCK can no longer skip the test suite) OCC checkout pinned to a 40-hex ref (it was unpinned) RED PROVEN AGAINST A REF WHERE THE ARTIFACT EXISTS BUT IS WRONG, not merely absent: infra dev HAS ci.yml, HAS the contract-compliance job, HAS the checkout step -- it just runs the dead executor, couples the gate to the test pipeline, and pins nothing. All three exit 1 there, and 1 at a bogus SHA. The naive form of the decouple check is a VACUOUS GREEN and was rejected: 'count coupled needs: lines, require zero' passes against any ref with no ci.yml at all, since zero lines trivially contain zero couplings. A check that passes because the thing it inspects is ABSENT asserts nothing. The shipped form requires needs: lists to EXIST and none to couple the gate.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 7 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Closes OMN-14454
Unblocks omnibase_infra#2267 (the OMN-14436 canary), whose
occ-preflightfails withmissing_contract: OMN-14454.Why this isn't just OMN-14436's contract — a constraint that only appeared once checks actually ran
OMN-14436's contract is OCC-specific (
pytest tests/test_dod_runner_ratchet.py,mypy scripts/ci/…,ruff scripts/ci/…). Run withcwd = the infra tree— exactly what the canary makes happen — it BLOCKs:A cross-repo ticket cannot have one contract that passes in both repos. Note which two survived: the
gh apicontent reads. They read GitHub, not the filesystem — workspace-independent, which is the same property that makesOMN-14418/OMN-14409the known-good control group for this canary.Every check here is a
gh apicontent read, for exactly that reason.Three product-observing checks on #2267
dod-verify-2267-runner-executes-against-productrun_contract_compliance_check.py(not the deadvalidate-yaml, which never ran a singlecheck_value— a green check meant only "OCC's YAML parses")dod-verify-2267-gate-cannot-suppress-testscontract-complianceis in noneeds:list — a BLOCK can no longer skip the entire test suitedod-verify-2267-occ-checkout-pinnedref:— it was unpinned, the same hazard that caused the original incidentRED proven against a ref where the artifact EXISTS but is WRONG
Not merely where it's absent. infra dev HAS
ci.yml, HAS thecontract-compliancejob, HAS the checkout step — it just runs the dead executor, couples the gate to the test pipeline, and pins nothing.needs:lists)ref:)The naive decouple check is a VACUOUS GREEN — rejected here
"Count coupled
needs:lines, require zero" passes against any ref with noci.ymlat all — zero lines trivially contain zero couplings.The shipped form requires
needs:lists to exist (N > 0) and none to couple the gate. That's why the bogus-SHA column above is RED rather than a false green.Re-proven from the YAML-round-tripped
check_value.check_receipt_hardeningrc=0 ·lint_contract_check_valuesrc=0 · all three non-inert under the new runner.