Repository navigation
ci: Harden Drivers CI Workflow and Correct False Claims - #174
Conversation
Add workflow_dispatch and a weekly schedule to drivers.yml for toolchain-rotation detection, add an SPM global-cache step to the ios job, and correct three rationale-comment claims falsified or made ambiguous by PRs #168-#172: the stale ios worst-case timing, the ambiguous native-file count, and the proto/** filter justification (now scoped to Android only, since a green ios job does not prove committed Swift bindings are in sync with proto).
|
Warning Review limit reached
Next review available in: 6 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Meta
0sg1generated by fab-kit v2.16.8
Pipeline: intake ✓ → apply ✓ → review ✓ → hydrate ✓ → ship → review-pr
Summary
drivers.ymlis the only automated verification the native drivers have, and nothing pins its toolchain, so amacos-latestimage rotation breaks the build silently until a red check lands on an unrelated PR. Separately, three of the file's own rationale comments — held up by this repo's comment policy as the canonical positive example — had drifted false or ambiguous following PRs #168–#172. This change adds on-demand and weekly-scheduled runs plus an SPM cache todrivers.yml, and corrects those three claims in place without touching any surviving rationale.Changes
workflow_dispatchand a weeklyschedule(Mon 05:17 UTC) so toolchain rotation surfaces as an attributable scheduled-run failure instead of a misattributed red check on the next PR that happens to touch a driver path~/Library/Caches/org.swift.swiftpm), keyed onPackage.resolved, sincebuild-drivers-ios.shwipes DerivedData every run and all 22 packages otherwise re-resolve over the network at the 10x macOS billing rateiosjobFindings came from an independent adversarial review of PRs #168–#172. Memory hydration updated
docs/memory/ci/pr-quality-gate.mdanddocs/memory/drivers/grpc-contract.md(plus their domain indexes) with the corrected facts and the proto/iOS-desync caveat.Note: this PR touches
drivers.yml, which is in its ownpathsfilter, so thedriversworkflow will run on this PR — expected and accepted (costs macOS minutes).