fix: Harden WebGUI Linear release workflow#2647
Merged
Merged
Conversation
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.
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe release workflow pins checkout, adds a tag-range fallback, records GitHub PR URLs and passes their path/count to the Node sync script; the script loads those PR URLs and attaches any linked Linear issues using generalized URL-to-issue helpers and related-release linking. ChangesRelease Workflow Improvements
Sync script: related releases and attachment-based issue sync
Sequence Diagram(s)sequenceDiagram
participant Workflow
participant NodeScript
participant LinearAPI
Workflow->>Workflow: checkout pinned to v6.0.2
Workflow->>Workflow: compute RANGE_SPEC (use ${TAG_NAME}^..${TAG_NAME} fallback)
Workflow->>Workflow: extract PR numbers and write GITHUB_PR_URLS_PATH
Workflow->>NodeScript: set env GITHUB_PR_URLS_PATH / github_pr_url_count
NodeScript->>LinearAPI: findIssuesForAttachmentUrl(url) for each githubPrUrl
LinearAPI->>NodeScript: return linked Linear issue IDs (skip archived/unlinked)
NodeScript->>LinearAPI: attach/de-duplicate issues on release
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 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 docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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 123-125: The current grep pipeline is too broad because it picks
up parenthetical issue references like "(`#123`)"; restrict the extraction to
actual merge PR lines by changing the first grep to only match explicit merge
commit messages (e.g. grep -Eo "Merge pull request #[0-9]+") instead of also
matching "\(#[0-9]+\)"; update the pipeline that uses LOG_PATH (the two grep |
sort -u || true sequence) so it extracts only numbers from "Merge pull request
#[0-9]+" matches, ensuring curl calls to /pulls/{id} won’t receive issue IDs and
fail the job.
🪄 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: 536767ec-43ac-425c-b933-13e124f0fd6c
📒 Files selected for processing (1)
.github/workflows/linear-release.yml
Purpose of the change: - Support WebGUI release sync when the only issue relationship is stored in Linear as a GitHub PR attachment. Previous behavior: - The workflow scanned commit and PR text for Linear issue IDs and FeatureOS URLs only. - If a PR was linked from Linear but did not mention the Linear ticket in GitHub, release sync could miss the issue. Why that was a problem: - WebGUI release membership would be incomplete for issues where the canonical link lives in Linear's GitHub integration attachments. What this changes: - Records the GitHub PR URL for each PR discovered from the release tag range. - Passes those PR URLs into the Linear sync script. - Resolves matching Linear attachments with attachmentsForURL and attaches the linked issues to the release. - Treats missing PR attachments as normal and avoids noisy skipped entries. How it works: - The existing PR number parsing and PR metadata fetch stay in place. - The script uses the same attachment lookup path for FeatureOS URLs and GitHub PR URLs, then dedupes issues before applying addedReleaseIds.
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/linear-release.yml (1)
124-137:⚠️ Potential issue | 🟠 Major | ⚡ Quick winConstrain inline
(#N)extraction to commit subjects to avoid false PR lookups.Line 125 currently scans full commit bodies for
(#N), which can capture non-PR references and make Line 136 fail withcurl -fsSLagainst/pulls/{id}.Suggested patch
git log --format='%B%n' "$RANGE_SPEC" > "$LOG_PATH" + SUBJECTS_PATH="${RUNNER_TEMP}/linear-release-subjects.txt" + git log --format='%s' "$RANGE_SPEC" > "$SUBJECTS_PATH" PR_NUMBERS="$( - grep -Eo 'Merge pull request #[0-9]+|\(#[0-9]+\)' "$LOG_PATH" \ + grep -Eo 'Merge pull request #[0-9]+|\(#[0-9]+\)$' "$SUBJECTS_PATH" \ | grep -Eo '[0-9]+' \ | sort -u || true )"🤖 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/workflows/linear-release.yml around lines 124 - 137, The current PR_NUMBERS extraction greps the entire "$LOG_PATH" which captures `(`#N`)` anywhere (including commit bodies) and leads to invalid PR lookups; change the pipeline so the grep runs only against commit subjects instead of the full log file — for example, replace reading "$LOG_PATH" with a command that emits only commit subjects (e.g. git log --pretty=format:%s ...) or filter "$LOG_PATH" to only subject lines before applying grep -Eo 'Merge pull request #[0-9]+|\(#[0-9]+\)'; keep the rest of the pipeline (sort -u, loop over PR_NUMBERS, writing to GITHUB_PR_URLS_PATH and the curl call) intact. Ensure you update the PR_NUMBERS assignment (the variable and the grep invocation) so only subject-line matches produce PR IDs.
🤖 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.
Duplicate comments:
In @.github/workflows/linear-release.yml:
- Around line 124-137: The current PR_NUMBERS extraction greps the entire
"$LOG_PATH" which captures `(`#N`)` anywhere (including commit bodies) and leads
to invalid PR lookups; change the pipeline so the grep runs only against commit
subjects instead of the full log file — for example, replace reading "$LOG_PATH"
with a command that emits only commit subjects (e.g. git log --pretty=format:%s
...) or filter "$LOG_PATH" to only subject lines before applying grep -Eo 'Merge
pull request #[0-9]+|\(#[0-9]+\)'; keep the rest of the pipeline (sort -u, loop
over PR_NUMBERS, writing to GITHUB_PR_URLS_PATH and the curl call) intact.
Ensure you update the PR_NUMBERS assignment (the variable and the grep
invocation) so only subject-line matches produce PR IDs.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0a7d6488-1ea4-4088-9041-52477b446664
📒 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 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 of the change: - Make workflow_dispatch testing work for historical WebGUI release tags. Previous behavior: - Manual runs checked out the requested tag directly. - Historical tags do not contain the new sync script, so the workflow failed with MODULE_NOT_FOUND. Why that was a problem: - The workflow could not be tested against previous tags from the PR branch even though the tag metadata was fetched successfully. What this changes: - Manual workflow_dispatch runs now check out the workflow ref/branch while still resolving and operating on the requested tag_name. - Tag push runs continue to check out the pushed tag. How it works: - The checkout ref uses github.ref for workflow_dispatch and github.ref_name for tag pushes.
Purpose of the change: - Keep active QA work attached to the next prerelease and stable companion release from WebGUI tag sync. Previous behavior: - WebGUI release sync attached discovered Linear issues only to the exact tag release. - Existing QA Ready issues already on a prerelease were not swept into the next planned prerelease. - WebGUI-linked prerelease issues could miss the stable companion release. Why that was a problem: - QA Ready work could fall out of the next release bucket even though it still needed validation. - Stable release planning would not reliably track all work that passed through the prerelease series. What this changes: - Internal/prerelease tag sync now resolves the exact prerelease, stable companion, and next planned prerelease releases. - Active issues are attached to all applicable release buckets. - Completed/internal-released issues are removed from the next planned prerelease while preserving exact prerelease and stable companion memberships. - Existing issues already attached to the exact prerelease are swept through the same policy, even if they were not discovered from the current tag diff. How it works: - The sync script creates or updates the stable companion as Planned and the next prerelease as Planned. - Issue state is loaded from Linear and used to decide whether to carry or remove next-prerelease membership. - Linear issue updates use addedReleaseIds and removedReleaseIds without changing workflow state.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
actions/checkoutto the immutable commit currently referenced byv6.0.2.TAG^..TAGwhen possible so the workflow does not scan full tag ancestry.Merge pull request #123, avoiding accidental issue references like(#123).workflow_dispatchtesting against historical tags by checking out the workflow branch while still resolving the requestedtag_name.Review Notes
de0fac2e4500dabe0009e67214ff5f5447ce83dd.PREVIOUS_TAGrange walked too much history. Fixed with parent-bounded range and a parentless fallback.Merge pull request #[0-9]+while preserving numeric extraction,sort -u, and|| truebehavior.attachmentsForURLnow resolves the issue from the PR URL.tag_nameduringworkflow_dispatchfailed for historical tags because the tag did not contain the new script. Fixed by checking outgithub.reffor manual runs.Validation
git diff --checknode --check .github/scripts/sync-linear-release.mjsruby -e 'require "yaml"; YAML.load_file(".github/workflows/linear-release.yml"); puts "yaml ok"'2645fromMerge pull request #2645 ...and ignores parenthetical(#2646)/(#123)references.6.2.2^..6.2.2when a parent exists.attachmentsForURL(https://github.com/unraid/webgui/pull/2645)resolvedOS-239, and the sync script attachedOS-239to7.3.1-rc.0.3without changing itsQA Readystate.tag_name=7.3.1-rc.0.3; it synced the existing Linear Release and attachedOS-239idempotently.OS-239isQA Readyand attached to7.3.1-rc.0.3,7.3.1-rc.0.4, andUnraid OS 7.3.1 Stable.Summary by CodeRabbit
Chores