feat: Generate Linear release notes from WebGUI tags#2648
Conversation
|
Warning Review limit reached
More reviews will be available in 47 minutes and 54 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 refill rate. 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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughThis PR enhances Linear release automation to coordinate multiple release tracks and enrich release notes with GitHub PR context. The workflow now collects PR URLs and metadata during commit analysis, passing them to the sync script. The script resolves companion stable and next-prerelease releases, syncs managed release notes incorporating PR summaries and linked issues, and reconciles issue membership across all related releases with state-based carry-forward logic. ChangesLinear Release Sync Enhancement
Sequence Diagram(s)sequenceDiagram
participant GitHubActions as GitHub Actions
participant SyncScript as sync-linear-release.mjs
participant LinearAPI as Linear GraphQL
GitHubActions->>SyncScript: PR URLs, PR summaries, log paths
SyncScript->>LinearAPI: resolveRelatedReleases → upsert stable + next-prerelease
LinearAPI-->>SyncScript: stable & next releases
SyncScript->>LinearAPI: build release notes from PR summaries + issues
SyncScript->>LinearAPI: upsert managed release note (HTML markers)
LinearAPI-->>SyncScript: release note created/updated
SyncScript->>LinearAPI: for each issue: syncIssueToReleases across primary/stable/next
LinearAPI-->>SyncScript: issue memberships updated
SyncScript->>GitHubActions: summary with PR count
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 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)
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: 1
🧹 Nitpick comments (1)
.github/scripts/sync-linear-release.mjs (1)
540-565: ⚖️ Poor tradeoffPagination limit may miss issues for large releases.
findIssuesForReleasefetches onlyfirst: 100issues. If a release has more than 100 linked issues, subsequent issues won't be processed for carry-forward logic.Consider either documenting this as an acceptable limitation (releases rarely exceed 100 issues) or implementing pagination. For now, this is likely sufficient for the expected scale.
🤖 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/sync-linear-release.mjs around lines 540 - 565, findIssuesForRelease currently requests only the first 100 issues (query uses issues(first: 100)), which can drop issues for large releases; update the function (findIssuesForRelease) to paginate through issues using the GraphQL cursor-based pagination (use issues(first, after) and loop/recursively call graphql until pageInfo.hasNextPage is false, aggregating nodes) so all linked issues for the given releaseId are returned, or alternatively add a clear comment documenting the 100-item limit if you intend to keep the current 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.
Inline comments:
In @.github/workflows/linear-release.yml:
- Around line 132-151: The loop over PR_NUMBERS lacks handling for failed curl
requests which leaves PR_JSON_PATH empty/invalid and breaks jq/PR_TITLE logic;
after the curl call that writes to PR_JSON_PATH, check its exit status and/or
validate the file (e.g., ensure valid JSON or non-empty) and if the fetch failed
skip this PR_NUMBER with a logged warning, do not run jq or printf for that PR,
and still cleanup PR_JSON_PATH; update the block referencing curl, PR_JSON_PATH,
jq, PR_TITLE and PR_SUMMARY_PATH to perform this validation and early-continue
on failure.
---
Nitpick comments:
In @.github/scripts/sync-linear-release.mjs:
- Around line 540-565: findIssuesForRelease currently requests only the first
100 issues (query uses issues(first: 100)), which can drop issues for large
releases; update the function (findIssuesForRelease) to paginate through issues
using the GraphQL cursor-based pagination (use issues(first, after) and
loop/recursively call graphql until pageInfo.hasNextPage is false, aggregating
nodes) so all linked issues for the given releaseId are returned, or
alternatively add a clear comment documenting the 100-item limit if you intend
to keep the current behavior.
🪄 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: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 9cbee431-5bff-4bdd-913a-b2fd4db6dda6
📒 Files selected for processing (2)
.github/scripts/sync-linear-release.mjs.github/workflows/linear-release.yml
Purpose of the change: - Address review feedback on the WebGUI Linear release workflow while keeping the patch minimal. Previous behavior: - The workflow used the mutable actions/checkout@v6 tag. - Tags without a previous semver tag used RANGE_SPEC equal to the tag name, causing git log to walk full ancestry. - PR metadata collection only recognized merge commits shaped as Merge pull request #123. Why that was a problem: - Mutable action tags can be retargeted upstream. - A first-tag release could scan unrelated historical commits and attach unrelated Linear metadata. - Squash-merged PRs with commit messages like Fix thing (#123) would not have their PR body scanned for Linear or FeatureOS links. What this changes: - Pins actions/checkout to the current v6.0.2 commit SHA. - Uses TAG^..TAG for first-tag ranges when a parent exists, with the old tag fallback only for parentless commits. - Extends PR number extraction to include squash-merge (#123) patterns while preserving numeric extraction, sorting, and dedupe. How it works: - The existing PR lookup loop remains unchanged; it receives a broader but still numeric-only PR number list. - The git range emitted by Resolve tag remains bounded before the later git log call uses it.
Purpose of the change: - Address review feedback on the WebGUI Linear release workflow PR parsing. Previous behavior: - PR number extraction matched both explicit merge commits and any parenthetical number shaped like (#123). Why that was a problem: - Ordinary issue references in commit messages could be treated as PR numbers and sent to the GitHub pulls API, causing the workflow to fail. What this changes: - Restricts PR number extraction to explicit Merge pull request #123 commit messages. - Keeps the existing numeric extraction, sort -u dedupe, and || true fallback behavior. How it works: - The first grep now emits only Merge pull request #[0-9]+ matches before the second grep extracts digits for the existing curl loop.
- Purpose: let the webgui tag workflow own user-facing Linear release notes for the active tag.\n- Before: the workflow synced Linear releases and issue membership but did not write release notes from the tag's commit or PR range.\n- Problem: stable release notes were being filled by release-diff internals instead of webgui-facing release context.\n- New behavior: the workflow records PR summaries, linked Linear IDs, FeatureOS links, and commit metadata, then syncs an idempotent Version <tag> release note.\n- How it works: the collection step emits PR summary and log paths, and the Node sync script creates or updates a marker-managed Linear release note attached to the active tag release.
elibosley
force-pushed
the
codex/webgui-linear-release-notes
branch
from
de06bf8 to
1e0ddeb
Compare
1 participant
Summary
Validation
node --check .github/scripts/sync-linear-release.mjsruby -e 'require "yaml"; YAML.load_file(".github/workflows/linear-release.yml"); puts "yaml ok"'Summary by CodeRabbit
Release Notes
New Features
Chores