Repository navigation
Conversation
Two of the five requested items are checks that produce fixes, not reporting, so they get their own step ahead of the report: unresolved bot replies across every PR opened (a review can arrive after merge, and a rate-limited bot leaves commits unreviewed behind a green checks list), and whether the linter set still matches the languages this repo actually contains. The other three are offers, so they join the section that already asks what to do next - renamed from 'Then ask, and only then' to 'Aftermath': trigger and re-measure the scheduled workflows, widen valgrind/helgrind/ fuzzing at named gaps rather than in general, and add coverage cases for the branches gcovr shows as never taken. Old step 24 becomes 25; the phase table, the report question count and every cross-reference move with it.
|
Warning Review limit reached
Next review available in: 15 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: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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 |
Separates three classes so the offer cannot destroy anything: work of yours that never landed (and was therefore invisible to run-all.sh, which reads git ls-files), the pre-existing dirt recorded at step 1 which stays untouched, and the superrepo gitlink bump - invisible from inside the target and the easiest thing in the job to forget.
1 participant
TL;DR
Two of the six are checks that produce fixes, so they get their own step
ahead of the report rather than becoming sentences in it. The other four are
offers, so they join the section that already asks the user what to do next —
renamed from "Then ask, and only then" to Aftermath.
Old step 24 becomes 25. The prompt is now 25 steps in 6 phases.
New step 24 — post-adoption checks
Both are only checkable once every PR has merged.
Unresolved bot replies across every PR the job opened. A review bot replies on
its own schedule; CodeRabbit rate-limits per developer, so a review can arrive
after you merged and a reply to your reply arrives later still. Nothing notifies
you, and a merged PR is not a closed conversation. The step distinguishes two
cases that look identical from the checks list: a finding you never answered, and
a commit that was never reviewed at all because the bot could not start. The
second is a coverage gap to state, not silence to read as clean.
The linter set is the target's, not the reference's. Step 15 kept every
checker the target already ran, but that was a merge decision made early and the
file set has moved since. Three failure modes, all of which report clean: a
language present with no checker, a checker whose language left the repo, and
LINT_ONLYinlint.ymlnaming a checker that does not exist. Nothingcross-checks that string against the scripts on disk.
Aftermath — four added offers
Each costs real CI time or changes code the adoption deliberately did not touch,
which is why they are offered rather than taken:
ci-deep.ymlandbump.ymlareschedule-driven and have never run on a freshly adopted module, so nothing has
proven they work outside the PR lane. Trigger them now rather than discovering a
broken cron in four weeks, and state the runner cost first.
reference shapes and verified to fire. Widening is separate work, and the offer
must name the specific gaps found; "more fuzzing" without a target buys little.
offer cases for them. Coverage stays a report and not a gate: the offer is more
meaningful assertions, each with its negative control, never a higher number.
cannot destroy anything: work of yours that never landed (and was therefore
invisible to
run-all.sh, which readsgit ls-files), the pre-existing dirtrecorded at step 1 which stays untouched, and the superrepo gitlink bump, which
is invisible from inside the target.
Report question 6 is new, carrying the bot-review coverage fact out of step 24.
Testing
No executable content. Verified mechanically:
step Nreference resolves to a heading that exists (no danglers)step 24-as-last,1–24,23–24,the 24-step job, or"four follow-up questions" reference
The cross-reference sweep grepped the numbering vocabulary rather than the
sentences changed, which is what caught
the 24-step jobin the forwardingsection at the end of the file.