(MOT-4299) fix(release): keep engine builtins out of the candidate interface gate - #698
Conversation
…terface gate The harness 1.7.0 candidate smoke failed on untyped schemas from iii-stream — an engine-hosted builtin the harness install enables for console streaming, which landed in the workers-baseline diff and was gated as if it were part of the released surface. Engine builtins are not installable from the registry and their schemas are not this repo's to fix: exclude them from target-worker resolution. Also run the smoke's interface-gate scripts from the pipeline ref instead of the release tag, so a dispatched re-run of an already published candidate (release SOP § re-run) picks up gate fixes without re-tagging. On tag pushes both refs coincide, so tag-triggered runs are unchanged.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
Next review available in: 18 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
skill-check — worker0 verified, 54 skipped (no docs/).
Four for four. Nicely done. |
1 participant
Problem
The harness 1.7.0 staged release (run 30955188088) published to
harness@nextsuccessfully but died in candidate validation:None of those belong to harness.
_resolve_target_worker_namestreats every worker that appears after the baseline snapshot as part of the released surface — and the harness install enables the engine'siii-streambuiltin (console streaming) mid-boot, landing it in the diff. Earlier releases today (providers, llm-router, console) passed because their installs don't touch engine builtins. A builtin is not installable from the registry and its schemas are not this repo's to fix.Fix
build_publish_payload.py: exclude the engine-hosted worker set (configuration,iii-observability,iii-state,iii-stream,iii-worker-manager,iii-worker-ops) from baseline-diff target resolution, with tests for both the exclusion and the builtin-only-diff fallback._candidate-smoke.yml: run the interface-gate scripts from the pipeline ref (second checkout) instead of the release tag, so the SOP's dispatched re-run of an existing candidate picks up gate fixes without re-tagging. Tag-push runs are unchanged (both refs coincide).Unblocks
After merge: Actions → Release →
workflow_dispatchwith tagharness/v1.7.0re-validates the already-published candidate (publish is idempotent per the SOP), records evidence, and reopens the path to promotion.