Fix release docs automation#9071
Conversation
There was a problem hiding this comment.
Pull request overview
Improves the “Update Docs” automation by speeding up the docs-update script with parallel processing and making PR labeling more robust in the workflow.
Changes:
- Parallelize per-file Claude update calls in
.github/scripts/update_docs.pyusingThreadPoolExecutor, and add a thread-safe logging helper. - Ensure the
release-docslabel exists before applying it in.github/workflows/update-docs.yml.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
.github/workflows/update-docs.yml |
Adds a pre-step to create/ensure the release-docs label before creating PRs. |
.github/scripts/update_docs.py |
Runs file updates in parallel with thread-safe logging and updated log formatting. |
Comments suppressed due to low confidence (1)
.github/scripts/update_docs.py:247
- The comment above the "content-quality guards" says they "skip a version with a warning" but these checks now raise to abort processing. Update the comment so it matches the actual (fail-fast) behavior.
# --- API response integrity checks (raise -> file marked as failed) ---
# These guard against malformed or truncated API responses before we touch
# the file. They are distinct from the content-quality guards below, which
# are softer checks that skip a version with a warning rather than failing it.
|
Warning Review limit reached
More reviews will be available in 49 minutes and 55 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate 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 see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe docs update script now caps multi-version runs, builds prompts with truncation and ESR context, validates Claude responses, and processes files in parallel. The workflow creates the ChangesDocs update automation
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/scripts/update_docs.py (1)
208-211: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAlign the docstring with the hard-fail behaviour.
Lines 209-210 still describe quality failures as skipped, but Lines 275-285 now raise
RuntimeError.♻️ Proposed docstring update
- Version-level quality failures (empty response, too-short response) are logged - and skipped via continue -- they do not surface as a file-level status. + Version-level quality failures (empty response, too-short response) raise + RuntimeError so the caller marks the file as failed and prevents partial application.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/scripts/update_docs.py around lines 208 - 211, Update the docstring for the status-returning logic in update_docs.py so it matches the current hard-fail behavior. The current description still says version-level quality failures are logged and skipped via continue, but the implementation now raises RuntimeError for those cases; adjust the text near the function or helper that returns "updated", "unchanged", or "not_found" to say quality failures surface as exceptions while only non-fatal cases are skipped.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/scripts/update_docs.py:
- Around line 261-269: The truncated-file handling in update_docs.py is silently
slicing Claude’s returned head in the update flow, which can drop content before
the original tail is reattached. Update the logic around the truncated/updated
length check in the file-reconstruction path so it does not trim the head;
instead, treat an oversized head as a safe failure condition (or otherwise
preserve full content) before combining it with the tail, using the existing
update flow around MAX_SEND_CHARS and truncated.
- Around line 342-374: The missing-docs path is currently treated as a warning
via the results["not_found"] bucket in update_docs.py, which allows the workflow
to continue; change the control flow in the ThreadPoolExecutor result handling
so any file reported as not_found is treated as a hard failure and causes the
script to exit non-zero. Use the existing update_file / future.result()
aggregation and the final summary output to identify the missing-path case, then
add failure handling that surfaces the missing filepath(s) and stops PR
generation when required docs are absent.
---
Nitpick comments:
In @.github/scripts/update_docs.py:
- Around line 208-211: Update the docstring for the status-returning logic in
update_docs.py so it matches the current hard-fail behavior. The current
description still says version-level quality failures are logged and skipped via
continue, but the implementation now raises RuntimeError for those cases; adjust
the text near the function or helper that returns "updated", "unchanged", or
"not_found" to say quality failures surface as exceptions while only non-fatal
cases are skipped.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0ca8b06d-dfe5-44ba-a064-8973f9526f97
📒 Files selected for processing (2)
.github/scripts/update_docs.py.github/workflows/update-docs.yml
Summary
update_docs.py: parallelizes file processing withThreadPoolExecutor(up to 5 workers), adds thread-safetprinthelper to prevent interleaved log lines, and updates log messages to use[filepath]prefix formatupdate-docs.yml: addsgh label create "release-docs"step beforegh pr createso the label is created if absent (no-ops if it already exists)Test plan
release-docslabel is created automatically on first run in a repo where it doesn't exist🤖 Generated with Claude Code