ci: close issues on release

[Brentlok]

Summary by CodeRabbit

• Chores
  • Automated cleanup after releases now closes any open “pending release” issues once a release is published.
  • Adds a release notice to each matched issue with the new version and release link.
  • Skips this cleanup step during dry runs.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6d7cc1bc-2b9c-4322-bec3-9833f461c160

📥 Commits

Reviewing files that changed from the base of the PR and between b5a1c97 and e3616c8.

📒 Files selected for processing (1)

• .github/workflows/release.yaml

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/release.yaml

---

📝 Walkthrough

Walkthrough

Adds a conditional GitHub Actions release step that, after a non-dry-run publish, looks up the release URL and closes open issues labeled pending-release with a comment.

Changes

Release workflow automation

Layer / File(s)	Summary
Post-release pending issue closure step .github/workflows/release.yaml	Adds a step, gated on inputs.dry_run == false, that reads the version from packages/uniwind/package.json, retrieves the release URL via gh release view, then removes the pending-release label, comments, and closes each matching open issue.

Estimated code review effort: 2 (Simple) | ~10 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseWorkflow
  participant PackageJson
  participant GitHubReleases
  participant GitHubIssues

  ReleaseWorkflow->>PackageJson: Read version from package.json
  ReleaseWorkflow->>GitHubReleases: gh release view v$VERSION
  GitHubReleases-->>ReleaseWorkflow: Release URL
  ReleaseWorkflow->>GitHubIssues: List open issues labeled pending-release
  GitHubIssues-->>ReleaseWorkflow: Matching issues
  loop each pending-release issue
    ReleaseWorkflow->>GitHubIssues: Remove pending-release label
    ReleaseWorkflow->>GitHubIssues: Post release comment
    ReleaseWorkflow->>GitHubIssues: Close issue
  end

Loading

Possibly related PRs

• uni-stack/uniwind#426: Updates the same release workflow with release orchestration and permissions changes that this post-release closure step builds on.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: closing pending issues as part of the release CI workflow.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/close-issues-on-release

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

This PR adds a new "Close pending release issues" step to the release workflow that runs after a non-dry-run release completes. It reads the bumped version from package.json, fetches the GitHub Release URL, then iterates over all open issues labelled pending-release to remove the label, post a release notice comment, and close each issue.

• The step is correctly gated by if: ${{ inputs.dry_run == false }} so it is skipped entirely for dry runs.
• Each gh sub-command uses || echo \"::warning::...\" for graceful degradation so a single issue failure won't abort the loop.
• GH_TOKEN is correctly set for the gh CLI, and issues: write is already declared in the job permissions.

Confidence Score: 4/5

The new step is safe to merge; two robustness concerns (pipefail and the 30-issue default limit) were raised in prior review rounds and are worth addressing before the first release with a large backlog of pending issues.

The step works correctly for typical conditions, but the previously-flagged issues around silent gh issue list failures and the default 30-issue cap remain unaddressed in the code. A release with more than 30 pending issues, or a transient auth/network error, would silently leave issues unclosed.

.github/workflows/release.yaml — specifically lines 109–114 where the gh issue list pipe and default limit apply.

Important Files Changed

Filename	Overview
.github/workflows/release.yaml	Adds "Close pending release issues" step; logic is straightforward but see previously-flagged pipefail and limit concerns.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant W as Workflow
    participant RI as release-it
    participant GH as GitHub API
    participant PKG as package.json

    W->>RI: "npx release-it (dry_run=false)"
    RI->>PKG: bump version
    RI->>GH: create tag + GitHub Release
    RI-->>W: done

    W->>PKG: read new VERSION
    W->>GH: gh release view vVERSION
    GH-->>W: RELEASE_URL

    W->>GH: gh issue list --label pending-release
    GH-->>W: list of issue numbers

    loop for each ISSUE
        W->>GH: gh issue edit --remove-label pending-release
        W->>GH: gh issue comment with release URL
        W->>GH: gh issue close
    end

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant W as Workflow
    participant RI as release-it
    participant GH as GitHub API
    participant PKG as package.json

    W->>RI: "npx release-it (dry_run=false)"
    RI->>PKG: bump version
    RI->>GH: create tag + GitHub Release
    RI-->>W: done

    W->>PKG: read new VERSION
    W->>GH: gh release view vVERSION
    GH-->>W: RELEASE_URL

    W->>GH: gh issue list --label pending-release
    GH-->>W: list of issue numbers

    loop for each ISSUE
        W->>GH: gh issue edit --remove-label pending-release
        W->>GH: gh issue comment with release URL
        W->>GH: gh issue close
    end

Loading

_{Reviews (2): Last reviewed commit: "chore: add error logging in release for ..." | Re-trigger Greptile}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/release.yaml (1)

114-118: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

One failing issue aborts processing of all remaining issues.

GitHub Actions runs run: steps with bash -e -o pipefail by default, so if gh issue edit, gh issue comment, or gh issue close fails for any single issue (e.g., a transient API error or a race where the issue was already closed), the whole loop — and step — aborts immediately, leaving the rest of the pending-release issues unprocessed with no indication of which ones succeeded.

🔧 Proposed fix to isolate per-issue failures

           gh issue list --state open --label "pending-release" --json number --jq '.[].number' | while read -r ISSUE; do
-            gh issue edit "$ISSUE" --remove-label "pending-release"
-            gh issue comment "$ISSUE" --body "New release $TAG is published: $RELEASE_URL"
-            gh issue close "$ISSUE"
+            gh issue edit "$ISSUE" --remove-label "pending-release" || echo "::warning::failed to remove label on #$ISSUE"
+            gh issue comment "$ISSUE" --body "New release $TAG is published: $RELEASE_URL" || echo "::warning::failed to comment on #$ISSUE"
+            gh issue close "$ISSUE" || echo "::warning::failed to close #$ISSUE"
           done

🤖 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/release.yaml around lines 114 - 118, The release workflow
loop in the pending-release cleanup step currently aborts on the first failing
GitHub CLI call, so one bad issue stops processing of the rest. Update the `gh
issue list ... | while read -r ISSUE` block in the release workflow to isolate
failures per issue, such as by handling errors around `gh issue edit`, `gh issue
comment`, and `gh issue close` inside the loop and continuing to the next
`ISSUE` even when one command fails. Keep the existing `pending-release`
processing logic but make the per-issue operations resilient so remaining issues
are still handled.

🤖 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/release.yaml:
- Line 114: The release workflow’s gh issue listing is subject to the default
30-item cap, so some pending-release issues may be skipped. Update the gh issue
list command in the release workflow to explicitly request enough results using
a limit option, and keep the rest of the loop logic unchanged so all matching
issues are processed.

---

Nitpick comments:
In @.github/workflows/release.yaml:
- Around line 114-118: The release workflow loop in the pending-release cleanup
step currently aborts on the first failing GitHub CLI call, so one bad issue
stops processing of the rest. Update the `gh issue list ... | while read -r
ISSUE` block in the release workflow to isolate failures per issue, such as by
handling errors around `gh issue edit`, `gh issue comment`, and `gh issue close`
inside the loop and continuing to the next `ISSUE` even when one command fails.
Keep the existing `pending-release` processing logic but make the per-issue
operations resilient so remaining issues are still handled.

🪄 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: defaults

Review profile: CHILL

Plan: Pro

Run ID: 223d4933-c05b-474b-af28-11a436db3633

📥 Commits

Reviewing files that changed from the base of the PR and between 22a6f67 and b5a1c97.

📒 Files selected for processing (1)

• .github/workflows/release.yaml