Repository navigation
Fix protected runner context check - #32
Conversation
|
Warning Review limit reached
Next review available in: 39 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 (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
|
Exact repair-head validation is green:
The failed protected run remains retained as artifact |
|
Protected candidate production is now complete and independently inspected. Exact merged source:
Downloaded candidate audit:
Inspection confirmed exactly 25 sorted fixed-path closure members and all member hashes; source commit/tree/run/attempt agreement; clean checkout; GitHub-hosted protected The report, attempt, validator result, and constrained attestation record all remain |
Outcome
Repairs the first protected-main publication candidate failure after PR #31.
The producer defined its report vocabulary as:
readonly RUNNER_ENVIRONMENT="github_hosted"That assignment shadowed GitHub's immutable default:
RUNNER_ENVIRONMENT="github-hosted"The protected-only comparison therefore rejected every real GitHub-hosted run even though the separate workflow gate had already established
GITHUB_REF_PROTECTED=true.This patch renames only the report-vocabulary constant to
REPORT_RUNNER_ENVIRONMENT, preserving GitHub's immutableRUNNER_ENVIRONMENTfor the protected-context check.Exact failure evidence
55a0ae0fad9fe5cfd20ed0a5fbddf6b80a5303c17508582f4ac01b6cd4533c135d7da5f238ad2149297162926598827012528765, protected context disagreement8450708477sha256:29c70446a4ba089b44621b254bd6ff54ca3a109a836ff8c60a4525e8e7059c27Validation
bash -n scripts/publication-candidate.sh69for locally unavailable WSLjq), proving it passes the protected-context gateRUNNER_ENVIRONMENT=self-hostedfails closed at the protected-context gate with exit65git diff --checkHead:
c0e3cd9230892e5863f3a291d7f750ba67a2ca3cTree:
5dc109a29888c7ac34e67cdd6fb84454947133e5Non-goals
No authority is created. The repair changes neither candidate contents nor validation semantics; reports and attestation-verification records remain
authoritative:false.Advances #21.