Prevent oversized GitHub release failures#4714
Conversation
|
+ci-status |
|
+ci-run-hosted |
CI StatusHead SHA: Only the required gate is active unless hosted CI is requested. |
Hosted CI RequestedTriggered 9 workflow(s) for View progress in the Actions tab. |
WalkthroughThe release task now bounds GitHub release bodies by compacting links and truncating oversized changelog content. It reports prepared-body sizes before publication, centralizes GitHub failure recovery, and documents the GitHub-only synchronization path. ChangesGitHub release body flow
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseTask
participant NotesPipeline
participant GitHub
participant SyncCommand
ReleaseTask->>NotesPipeline: Prepare changelog notes
NotesPipeline->>ReleaseTask: Return bounded release body
ReleaseTask->>GitHub: Publish release
GitHub-->>ReleaseTask: Report failure
ReleaseTask->>SyncCommand: Retry GitHub synchronization
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ast-grep (0.44.1)react_on_rails/spec/react_on_rails/release_rake_helpers_spec.rbast-grep timed out on this file 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 |
Greptile SummaryThis PR prevents oversized changelogs from blocking GitHub release publication. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (1): Last reviewed commit: "Prevent oversized GitHub release failure..." | Re-trigger Greptile |
| ERROR | ||
| end | ||
|
|
||
| report_github_release_notes_preflight!(version:, changelog_notes: has_changelog) |
There was a problem hiding this comment.
Minor: report_github_release_notes_preflight! calls github_release_notes(notes: changelog_notes, tag:) purely to print the before/after character counts, and then prepare_github_release_context (called later during actual publish) re-extracts the changelog section from disk and calls github_release_notes again with the same inputs. Not a correctness bug (the computation is a pure function and cheap), but it does double the compaction/truncation work and re-reads CHANGELOG.md a second time. Could thread the already-prepared notes through instead, if you want to avoid the duplicate work.
| compacted_notes = compacted_notes.gsub( | ||
| %r{\[(?:Issue|issue) (\d+)\]\(https://github\.com/shakacode/react_on_rails/issues/\1\)} | ||
| ) { "##{Regexp.last_match(1)}" } | ||
| compacted_notes.gsub(%r{\[([A-Za-z0-9](?:[A-Za-z0-9-]{0,38}))\]\(https://github\.com/\1\)}) do |
There was a problem hiding this comment.
Nit: this pattern will compact any [text](https://github.com/text) link whose text matches the trailing URL segment — not just real profile links — including things like [shakacode](https://github.com/shakacode) (an org page) or a coincidental repo-name link. That's likely fine in practice (relative links resolve the same way), but the char class also doesn't enforce GitHub's username rules (no leading/trailing/consecutive hyphens), so it'll happily "compact" some strings that aren't valid usernames at all. Worth a comment noting this is a best-effort heuristic, not a validator, if that's intentional.
Review: Prevent oversized GitHub release failuresOverviewThis PR fixes a real incident (17.0.0's release body exceeded GitHub's 125,000-char limit) by adding a preflight/prepare step for GitHub release bodies: compact same-repo PR/issue/profile links to short forms, and if still oversized, fall back to a Markdown-safe beginning/end excerpt with a tag-pinned link to the full changelog. The same preparation is applied to both Code quality
Correctness
Test coverageVery thorough — covers compaction with 800 entries, max-length (39-char) usernames, multibyte content near the limit (char vs byte length), balanced SecurityNo concerns — this only touches release-body text prepared for Risk/Blast radiusLow — this is maintainer-only release tooling, gated behind a manual Overall: solid, well-tested fix for a real release-blocking bug. Only minor nits noted inline; nothing blocking. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
rakelib/release.rake (1)
6738-6750: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueChain
gsubcalls using string backreferences.You can make this method more concise and idiomatic by chaining the
gsubcalls and using string backreferences ('\1') instead of blocks withRegexp.last_match(1).♻️ Proposed refactor
def compact_github_release_notes(notes) - compacted_notes = notes.gsub( - %r{\[PR (\d+)\]\(https://github\.com/shakacode/react_on_rails/pull/\1\)} - ) { "##{Regexp.last_match(1)}" } - compacted_notes = compacted_notes.gsub( - %r{\[(?:Issue|issue) (\d+)\]\(https://github\.com/shakacode/react_on_rails/issues/\1\)} - ) { "##{Regexp.last_match(1)}" } - compacted_notes.gsub(%r{\[([A-Za-z0-9](?:[A-Za-z0-9-]{0,38}))\]\(https://github\.com/\1\)}) do - username = Regexp.last_match(1) - "[#{username}](/#{username})" - end + notes + .gsub(%r{\[PR (\d+)\]\(https://github\.com/shakacode/react_on_rails/pull/\1\)}, '#\1') + .gsub(%r{\[(?:Issue|issue) (\d+)\]\(https://github\.com/shakacode/react_on_rails/issues/\1\)}, '#\1') + .gsub(%r{\[([A-Za-z0-9](?:[A-Za-z0-9-]{0,38}))\]\(https://github\.com/\1\)}, '[\1](/\1)') end🤖 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 `@rakelib/release.rake` around lines 6738 - 6750, Refactor compact_github_release_notes to chain the three gsub transformations directly and replace the PR and issue blocks’ Regexp.last_match(1) usage with string backreferences such as '\1'. Preserve the existing regex patterns and username-link replacement behavior.
🤖 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.
Nitpick comments:
In `@rakelib/release.rake`:
- Around line 6738-6750: Refactor compact_github_release_notes to chain the
three gsub transformations directly and replace the PR and issue blocks’
Regexp.last_match(1) usage with string backreferences such as '\1'. Preserve the
existing regex patterns and username-link replacement behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 6802d841-3b2a-4f3a-a4ff-371bd78be062
📒 Files selected for processing (3)
internal/contributor-info/releasing.mdrakelib/release.rakereact_on_rails/spec/react_on_rails/release_rake_helpers_spec.rb
Why
The 17.0.0 registry packages and tag published successfully, but GitHub rejected the final release description because the changelog section was 149,693 characters, over GitHub's 125,000-character limit. Rerunning the full release would risk republishing artifacts that already exist.
What changed
sync_github_releaseand fail closed if a prepared body is still oversized.sync_github_release[VERSION]recovery command and warn against rerunning registry publication.This exact implementation reduces the 17.0.0 body from 149,693 to 121,773 characters without dropping its changelog entries; that output matches the repaired live release.
Verification
bundle exec rspec spec/react_on_rails/release_rake_helpers_spec.rb— 743 examples, 0 failures.agents/bin/lint— passedgit diff --check— passedcodex review --uncommitted— clean after resolving all findingsv17.0.0release — non-draft, non-prerelease, 121,773-character bodyThe broad
.agents/bin/validate --changedrun reached and passed docs, lint, build, ESLint, Prettier, type-checking, and the release-helper suite, but its RBS-enabled all-gem RSpec phase produced unrelated Ruby 4.0.5/RBS dependency failures. As a control, an unrelated failing example passed standalone outside that RBS environment; the focused release suite remained green inside the broad run.Changelog
No user-facing changelog entry: this changes maintainer release tooling and internal release documentation.
Summary by CodeRabbit
Release Process
Documentation