ci: Notify pending release approvals via auto-managed issue#1950
Conversation
Adds a reconcile-style command that lists repository-wide waiting workflow runs, resolves each one's pending environment deployment, and creates/updates/closes a single tracking issue accordingly. TDD-covered with unit tests for the pure plan decision, body generation, and the gh-CLI-backed orchestration layer, following the deps-injection pattern from cancel-superseded-waiting-runs.
Runs every 15 minutes plus on native-cli-publish/dispatcher-publish completion, so an approval-waiting release run is never left silently stuck the way run 29917524403 was after PR #1933.
scripts/check-go-cli.sh flagged both on the new command.
|
Warning Review limit reached
Next review available in: 19 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?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 reviews. How do review 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 refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ 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 |
schedule/workflow_run only trigger from workflow files on the default branch (main), which has no cli/ directory; pin checkout to v3-beta so the scheduled run finds the reconcile implementation. Also add a concurrency group so an overlapping schedule + workflow_run trigger can't race to create duplicate tracking issues.
1 participant
Summary
User Impact
cli-releaseenvironment's manual approval would sit as awaitingrun in the Actions tab. Nothing else pointed at it, so it was easy to lose track of — as happened on 2026-07-22, when a waiting run after release PR chore: release v3-beta #1933 sat unapproved and blocked thev3.0.0-beta.60package release.Changes
waitingworkflow runs, resolves each one's pending environment, and reconciles a single tracking issue (create while waiting, update if the waiting set changes, close once resolved).workflow_dispatch, and on completion of the two publish workflows.Verification
scripts/check-go-cli.sh: format / vet / lint / tests / build all green (includes new unit tests for the issue-state decision logic and the gh-CLI-backed orchestration).GH_TOKEN=$(gh auth token) GITHUB_REPOSITORY=hatayama/unity-cli-loop go run ./cmd/notify-pending-release-approvals) twice in a row: no waiting runs currently exist, so both runs correctly reported "No changes needed." and the label was created idempotently without any issue being opened. The create/update/close paths against actual waiting runs are covered by unit tests, since no run is currently stuck waiting to exercise them live.