Repository navigation
fix(OMN-16296): drop onex_change_control from compute_workspace_provenance.py - #2837
Conversation
…nance.py #2822 removed onex_change_control from stage_workspace.sh, sibling_clone_manifest.sh, and check_sibling_lock_pins.py, but missed compute_workspace_provenance.py -- the script that runs inside Dockerfile.runtime's builder stage. Since stage_workspace.sh no longer stages a sibling-repos/onex_change_control directory, the builder stage now fails identically to the original OMN-16296 symptom, one step later: Missing sibling repo: /workspace/sibling-repos/onex_change_control Removes the stale entry from both places it appears in this file: WORKSPACE_PACKAGES (the per-sibling content-parity proof loop) and the siblings dict feeding the OMN-12989 pin-comparison block. Also removes the same stale entry from resolve_workspace_pins.py's SIBLING_DISTRIBUTIONS (unused, but documented as mirroring WORKSPACE_PACKAGES -- left stale it reproduces the same drift this ticket exists to close) and trims the two test fixtures that built a synthetic sibling-repos tree matching the old four/three-sibling set. Tests: tests/scripts/test_check_sibling_lock_pins.py, tests/scripts/test_compute_workspace_provenance_content_parity.py, tests/scripts/test_stage_workspace_vcs_provenance.py, tests/unit/scripts/test_check_sibling_lock_pins.py, tests/unit/scripts/test_resolve_workspace_pins.py -- 80 passed. Full tests/scripts + tests/unit/scripts -- 1640 passed / 6 skipped (macOS-only GNU-realpath skips, OMN-15134) / 1 pre-existing failure unrelated to this diff (test_fresh_deploy_fitness_gates.py::test_release_identity_passes_when_version_ahead, reproduces identically on clean dev tip before this change -- a pyproject-version-vs-published-version gate, not a scripts/tests-only PR concern). ruff format/check clean; pre-commit clean. Refs OMN-16296, OMN-16375.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 31 minutes Limit details: You’ve used the included review currently available. Your 119 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?Wait for the limit to reset, then comment An organization admin can change what happens after included review limits in Billing. How do review limits work?CodeRabbit enforces per-developer PR review limits within each organization. For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (3)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe workspace provenance and pin-resolution scripts no longer track ChangesWorkspace sibling removal
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This PR removes stale workspace references and updates the affected test fixtures; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
|
OCC autobind did not mint a companion for this PR: no changed-file candidate could be proven RED against the merge base, and emitting a PR-existence probe instead would be non-falsifiable evidence (OMN-15247). Hand-authored evidence is required. |
✅ Hostile Reviewer — PASSEDBlocking findings (critical): 0 Gate semantics (pilot phase)
Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8468/OMN-8524) |
#6861) * evidence: OCC companion pass 1 for OmniNode-ai/omnibase_infra#2837 * evidence: OCC companion self-bind for #6861 --------- Co-authored-by: node-occ-companion-effect <occ-companion-effect@omninode.ai>
scripts/deploy-agent has its own standalone uv sub-project with a duplicate test file exercising compute_workspace_provenance.py (scripts/deploy-agent/tests/unit/test_executor_workspace_provenance.py, wired into CI as "Deploy Agent Tests (OMN-15378)" -- a separate pytest root from tests/scripts/, so it wasn't covered by the targeted-test run in 139f222). test_provenance_script_passes_with_valid_local_installs staged three sibling dirs (omnibase_compat, onex_change_control, omnimarket) and asserted the manifest recorded 3 proofs -- both now stale after onex_change_control was dropped from WORKSPACE_PACKAGES. Trims the staged dir to the two siblings the script's proof loop still walks and updates the assertion to match (2 proofs). Tests: uv run --project scripts/deploy-agent --extra dev pytest scripts/deploy-agent/tests -q --tb=short -- 198 passed, 8 skipped. Refs OMN-16296, OMN-16375.
… contract-compliance (#2926) `ci.yml`'s `contract-compliance` step met an empty `PR_NUMBER` with `exit 0`. That was a vacuous pass on a required gate: "Contract Compliance Check" is a GATE_JOBS entry in `scripts/ci/ci_summary_gate.py`, and CI Summary is this repo's sole required branch-protection context, so the umbrella poller counted a run that evaluated zero DoD check_values as a *provable* pass. Unlike a red gate, a green one that checked nothing never prompts investigation. Scope correction against the ticket body, which claimed "every dev push": `on.push.branches` here is `[main]`, so this never fired on a dev commit. The two live fail-open events are push-to-main (release-synced fast-forwards) and merge_group -- the latter unexercised today (no registry repo has a queue on dev as of 2026-08-24) but a latent bypass of the sole required context the instant a queue returns, with zero further code change. The fix is resolution, not narrowing. Excluding push/merge_group with a job-level `if:` would publish a `skipped` check run, which branch protection counts as passing -- the OMN-14863 skip-vector class. So the job keeps running on all three events and `scripts/ci/resolve_contract_compliance_pr.py` answers which PR's check_values apply: the event's own number on pull_request (no API call, behaviourally identical to pre-fix), the `pr-<n>-` segment of the gh-readonly-queue ref on merge_group (no API call), or the merged source PR of the pushed commit via `gh api repos/{repo}/commits/{sha}/pulls`. Anything unresolved -- including a transient gh failure -- exits 1. Verified live against the real API before landing: dev 8ce11d5 -> #2923, and the three most recent main commits -> #2837/#2823/#2835, so the push path now evaluates a real scope rather than going spuriously red. An all-zero SHA exits 1 with no stdout. Ships with the OMN-15547 incident replay its own default-deny rule demands: two verbatim `gh api` captures under tests/fixtures/omn16508/ -- the empty association list GitHub really returns for a commit no merged PR produced (6d7090d, head of closed-unmerged #2890), which the guard must reject, and a 21KB merged-PR response (5b904d8 -> #2378) as the control that stops a hard-wired `return None` from replaying the incident while failing every legitimate push-to-main closed.
1 participant
Summary
#2822 removed
onex_change_controlfromstage_workspace.sh,sibling_clone_manifest.sh, andcheck_sibling_lock_pins.py, but missedcompute_workspace_provenance.py— the script that runs insideDockerfile.runtime's builder stage. Sincestage_workspace.shno longer stages asibling-repos/onex_change_controldirectory, the builder stage now fails identically to the original OMN-16296 symptom, one step later:This PR removes the stale entry from both places it appears in
compute_workspace_provenance.py:WORKSPACE_PACKAGES(the per-sibling content-parity proof loop) and the siblings dict feeding the OMN-12989 pin-comparison block. Also removes the same stale entry fromresolve_workspace_pins.py'sSIBLING_DISTRIBUTIONS(unused, but documented as mirroringWORKSPACE_PACKAGES— left stale it would drift silently) and updates two test fixtures that still expectedonex_change_controlin the manifest.Scripts/tests-only change — no runtime or contract surface touched.
Why now
Blocked on infra
devpublishing ahead of the last released version (thepyproject-version-vs-published-versionrelease-identity gate) —devnow carries 0.38.9 (tip 559ee46), so this rebases and passes cleanly.Refs OMN-16296, OMN-16375 (unblocks
build-workspace-candidate-runtime's provenance step).Test plan
uv run pytest tests/scripts/test_check_sibling_lock_pins.py tests/scripts/test_stage_workspace_vcs_provenance.py -q— 18 passeduv run pytest tests/scripts/test_check_release_identity.py -q— 15 passedEvidence-Ticket: OMN-16296
Evidence-Source: OCC#6861
Summary by CodeRabbit