Add stale issue cleanup workflow#3679
Conversation
Runs weekly on Mondays. Issues with no activity for 60 days get labeled "stalled" with a comment. Auto-closes after 30 more days (90 total). Exempts bounty, security, regression, and pinned labels, plus any issue with an assignee. PRs are not affected. Co-Authored-By: Claude Opus 4.6 <[email protected]>
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughA new GitHub Actions workflow is introduced to automate stale issue management. The workflow runs weekly, automatically labeling issues inactive for 60 days as "stalled" and closing them after 30 additional days, with exemptions for bounty, security, regression, and pinned issues. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
|
@coderabbitai review please |
|
30,60 days is wayy too short. Thats like saying every issue open should only be in our current cycle, this would kill any sort of backlog |
|
🧠 Learnings used✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/stale.yml:
- Around line 16-17: The stale workflow currently uses days-before-stale: 60 and
days-before-close: 30 which reviewers think is too aggressive; update the values
for days-before-stale and/or days-before-close in the workflow (e.g., set
days-before-stale to 180 or 365 and keep days-before-close at 30, or use another
team-agreed combination) and confirm the chosen thresholds with the team before
merging so the .github/workflows/stale.yml reflects the agreed inactivity
windows.
- Line 18: Add documentation that the workflow in .github/workflows/stale.yml
depends on a repository label named "stalled" (configured via the
stale-issue-label key) and specify the required color `#FFA500`; update README.md
or CONTRIBUTING.md with a short section describing the exact label name
("stalled"), color (`#FFA500`), and a one-line instruction for maintainers on how
to create the label via GitHub UI or gh CLI so the workflow can run correctly.
- Line 14: Update the GitHub Actions step that references the stale action (the
line using actions/stale) to a v10 release to avoid using the outdated v9;
change the reference from actions/stale@v9 to either the major version
actions/stale@v10 or pin to the exact latest patch actions/[email protected] for
reproducible builds so the workflow uses the supported release.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9da0ec39-bbc3-44de-b143-6c8f6ae21cd4
📒 Files selected for processing (1)
.github/workflows/stale.yml
.github/workflows/stale.yml
Outdated
| stale: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/stale@v9 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What is the latest version of actions/stale GitHub Action?
💡 Result:
The latest release of actions/stale is v10.2.0. [1]
In workflows, you can pin to the major line (actions/stale@v10) or to the exact release (actions/[email protected]). [2]
Update actions/stale to v10 or pin to v10.2.0 (latest).
The current v9 is outdated. The latest stable release is v10.2.0. For reproducibility, pin to the exact version (actions/[email protected]) or use the major version line (actions/stale@v10).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/stale.yml at line 14, Update the GitHub Actions step that
references the stale action (the line using actions/stale) to a v10 release to
avoid using the outdated v9; change the reference from actions/stale@v9 to
either the major version actions/stale@v10 or pin to the exact latest patch
actions/[email protected] for reproducible builds so the workflow uses the supported
release.
.github/workflows/stale.yml
Outdated
| days-before-stale: 60 | ||
| days-before-close: 30 |
There was a problem hiding this comment.
Consider longer inactivity windows per reviewer feedback.
Reviewer jb55 raised a valid concern that 60/30 days may be too aggressive for a project maintaining a long-term backlog. Legitimate feature requests or enhancement ideas can easily go 90+ days without activity while still being valuable.
Common alternatives:
- 180 days stale / 30 days close (210 total)
- 365 days stale / 30 days close (395 total)
Consider aligning with the team on acceptable thresholds before merging.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/stale.yml around lines 16 - 17, The stale workflow
currently uses days-before-stale: 60 and days-before-close: 30 which reviewers
think is too aggressive; update the values for days-before-stale and/or
days-before-close in the workflow (e.g., set days-before-stale to 180 or 365 and
keep days-before-close at 30, or use another team-agreed combination) and
confirm the chosen thresholds with the team before merging so the
.github/workflows/stale.yml reflects the agreed inactivity windows.
| with: | ||
| days-before-stale: 60 | ||
| days-before-close: 30 | ||
| stale-issue-label: 'stalled' |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Document the required "stalled" label setup.
The workflow requires a "stalled" label to exist. The PR description mentions creating it with color #FFA500, but this should be documented in the repository (e.g., README.md or CONTRIBUTING.md) so maintainers understand the prerequisite.
As per coding guidelines: "Update documentation when workflows change, especially this file, README.md, or developer notes."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/stale.yml at line 18, Add documentation that the workflow
in .github/workflows/stale.yml depends on a repository label named "stalled"
(configured via the stale-issue-label key) and specify the required color
`#FFA500`; update README.md or CONTRIBUTING.md with a short section describing the
exact label name ("stalled"), color (`#FFA500`), and a one-line instruction for
maintainers on how to create the label via GitHub UI or gh CLI so the workflow
can run correctly.
- v9 -> v10 (latest release is v10.2.0) - 60 days was too aggressive for an open-source project; 180 days gives contributors a full half-year before an issue is marked stalled - Close window stays at 30 days (210 total before auto-close) Co-Authored-By: Claude Opus 4.6 <[email protected]>
danieldaquino
added
the
pr-short
danieldaquino
left a comment
danieldaquino
left a comment
There was a problem hiding this comment.
Nice, I did not know this existed, very cool!
I like how it allows us to post a message before closing it, giving people time to react to it.
|
Passing to @jb55 for a final sign-off. |
|
@danieldaquino what are your thoughts on the time period, aren't they a bit aggressive? |
The original 90 days to close an issue might be a bit aggressive I agree, but the new 180 days + 30 day grace period seems reasonable to me. I don't mind keeping things as they are or longer periods if you have concerns, but we have to remember that we can always prevent something from closing in that 30 day grace period by providing any kind of update (like breaking it down, refining it, doing some preliminary research, assigning an AI agent to try it, adding a comment like "let's keep it open", or reopening after the fact). If something is truly important it will likely be brought back up by users or us after the fact, too. |
|
The worst case unhappy path is that we have to re-open something. We are not deleting issues. |
3 participants
Summary
actions/stale@v9) that labels inactive issues as stalled after 60 days and auto-closes them after 30 more days (90 total)bounty,security,regression, andpinnedlabels, plus any issue with an assigneeRationale
Issues that sit idle for a long time usually mean one of:
This keeps the issue tracker focused on what's actually active.
Config
Note
A
stalledlabel will need to be created for this to look right. Suggested: orange (#FFA500), description: "No activity — needs attention or triage"🤖 Generated with Claude Code
Summary by CodeRabbit