ci: disable scheduled stale issue and PR closing#2866
Conversation
Remove the daily cron schedule from the stale-check workflow so it no longer automatically marks or closes issues and PRs. The workflow_dispatch trigger is kept so it can still be run manually if needed.
Summary by CodeRabbit
WalkthroughThe stale-check workflow now runs only by manual dispatch. It also disables issue stale processing while keeping the PR stale and close thresholds unchanged. ChangesWorkflow trigger change
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
🔍 Container Scan Summary
Per-CVE detail lives in the per-service |
|
FWIW, this is the wrong approach. I understand not marking issues as stale, but PR's should be automatically marked as stale and closed after 60 days. 60 days is more than enough time for a contributor to fix their PR. |
Yes, I see the value in PR closing. Issues shouldn't be closed (doesn't make them not issues). Let me see if I can twiddle this for just issues. |
Set days-before-issue-stale to -1 to disable stale marking for issues and remove the issue stale message. PRs continue to be marked stale after 30 days of inactivity and closed after 7 more days.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/stale-check.yml (1)
1-13: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winRestore a schedule if PRs should still close automatically.
With
on.scheduleremoved, this workflow now runs only viaworkflow_dispatch, so the30/7stale-close thresholds are never enforced unless someone triggers it manually. That breaks the stated goal of disabling issue staling while keeping automatic PR stale handling.Suggested fix
on: + schedule: + - cron: '0 9 * * *' workflow_dispatch:As per path instructions, workflow trigger correctness must be validated; based on PR objectives, PRs are still expected to be marked stale and closed automatically.
🤖 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/stale-check.yml around lines 1 - 13, The workflow trigger in stale-check.yml currently only supports manual runs, so automatic PR stale handling is disabled. Restore an on.schedule trigger for the Stale PRs workflow in addition to workflow_dispatch, and keep the stale-close job configuration in stale-check.yml so the existing stale and close thresholds continue to run automatically without affecting issue staling.Source: Path instructions
🧹 Nitpick comments (1)
.github/workflows/stale-check.yml (1)
12-31: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winSerialize runs to avoid duplicate stale mutations.
This job mutates PR state across the whole repository. Without a
concurrencygroup, two manual dispatches can race and leave duplicate comments/labels or overlapping close attempts.Suggested fix
stale: name: Mark stale PRs + concurrency: + group: stale-prs + cancel-in-progress: false runs-on: linux-amd64-cpu4As per path instructions, GitHub Actions workflows should be reviewed for concurrency behavior.
🤖 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/stale-check.yml around lines 12 - 31, Add a workflow-level concurrency guard to the stale-check job so only one stale mutation run can execute at a time. Update the stale job in the workflow to use a unique concurrency group tied to the workflow/ref and disable cancel-in-progress if needed, so overlapping manual or scheduled runs don’t duplicate comments, labels, or close attempts. Use the stale job entry in the workflow as the location to apply this fix.Source: Path instructions
🤖 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.
Outside diff comments:
In @.github/workflows/stale-check.yml:
- Around line 1-13: The workflow trigger in stale-check.yml currently only
supports manual runs, so automatic PR stale handling is disabled. Restore an
on.schedule trigger for the Stale PRs workflow in addition to workflow_dispatch,
and keep the stale-close job configuration in stale-check.yml so the existing
stale and close thresholds continue to run automatically without affecting issue
staling.
---
Nitpick comments:
In @.github/workflows/stale-check.yml:
- Around line 12-31: Add a workflow-level concurrency guard to the stale-check
job so only one stale mutation run can execute at a time. Update the stale job
in the workflow to use a unique concurrency group tied to the workflow/ref and
disable cancel-in-progress if needed, so overlapping manual or scheduled runs
don’t duplicate comments, labels, or close attempts. Use the stale job entry in
the workflow as the location to apply this fix.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 378cd4fd-a55e-4876-a6fc-70f827346ffe
📒 Files selected for processing (1)
.github/workflows/stale-check.yml
Restore the daily cron trigger so PRs are automatically marked stale and closed without manual intervention. Add a concurrency group to prevent duplicate mutations from overlapping runs.
3 participants
Removes the daily cron schedule from
.github/workflows/stale-check.ymlso the workflow no longer automatically marks issues and PRs as stale or closes them. Theworkflow_dispatchtrigger is preserved so the check can still be triggered manually when needed.Related issues
Type of Change
Breaking Changes
Testing
Additional Notes
The stale workflow can still be run on-demand via the GitHub Actions UI using the
workflow_dispatchtrigger.