docs: correct analyzer-promotion, release trigger, and TPS003 references - #31
Conversation
Three claims in the doc set did not match the repo: - README (CI-matrix row and maintainer notes) and the AnalyzerReleases.Unshipped.md runbook all state that release.yml auto-promotes analyzer rules into Shipped.md via a "Promote analyzer rules to Shipped" step. No such step exists — release.yml's own header comment describes promotion as a manual maintainer commit, and that is what actually happens. Shipped.md is empty while TPS001-TPS003 have shipped in released NuGets from Unshipped.md, which is fine: rules are valid there indefinitely. The runbook's RS2007 claim is corrected too — RS2007 fires for an implemented rule that is listed in neither file, not for one that sits unshipped. Also notes that promotion should use the version that first shipped each rule rather than sweeping all three under whatever release is being cut. - The CI-matrix row listed release.yml's trigger as "scheduled"; it is `push` to master (plus workflow_dispatch), and only the release PR merging reaches the pack-and-publish job. - TPS003 shipped in 2.4.0 but README (repo layout, FAQ 12) and CONTRIBUTING still listed the analyzer as TPS001/TPS002 only. Adds a maintainer note for the codeql-action init/analyze SHA-pair invariant and the dependabot group that now enforces it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 22 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: Path: .coderabbit.yaml Review profile: ASSERTIVE 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 |
Doc-set corrections found while cutting 2.5.1. Three claims did not match the repo.
1. Analyzer promotion is manual, not automatic
README (the CI-matrix
release.ymlrow and the Maintainer notes bullet) and theAnalyzerReleases.Unshipped.mdrunbook all state thatrelease.ymlauto-promotes analyzer rules intoShipped.mdvia aPromote analyzer rules to Shippedstep.No such step exists.
release.ymlhas no promotion logic anywhere, and neither does any script —grep -rn Unshippedacross the repo hits only the workflow's own header comment and the analyzer.csproj'sAdditionalFilesline.release.yml's header comment describes promotion as "a deliberate maintainer commit, ideally folded into the release PR before it merges", which is what actually happens.Shipped.mdis empty while TPS001–TPS003 have shipped in released NuGets straight fromUnshipped.md— which is fine, and the docs now say so.The runbook's RS2007 claim is corrected too: RS2007 fires for an implemented rule listed in neither file, not for one that sits unshipped. The runbook also now says to promote under the version that first shipped each rule, rather than sweeping all three under whatever release happens to be cutting.
2.
release.ymltriggerThe CI-matrix row listed it as
scheduled; it ispushtomasterplusworkflow_dispatch, and only the release PR merging reaches the pack-and-publish job.3. TPS003
Shipped in 2.4.0, but README (repo layout, FAQ 12) and CONTRIBUTING still listed the analyzer as TPS001/TPS002 only.
Also
Adds a Maintainer notes bullet for the
codeql-actioninit/analyzeSHA-pair invariant and the dependabot group that now enforces it — see #25 / #28.Docs-only; no code or workflow behaviour changes. The
AnalyzerReleases.Unshipped.mdedit touches only;comment lines, leaving the### New Rulestable byte-identical, so the analyzer's release-tracking input is unchanged.