feat(stale)!: per-type timeouts for issues and PRs#31
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces a breaking change to the reusable stale workflow by decoupling the timeout configurations for issues and pull requests. By moving from generic inputs to specific parameters, the project gains better control over the lifecycle of different types of contributions, ensuring that active pull requests are not prematurely marked as stale compared to issues. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. The stale bot now knows what to do, / With separate times for PR and issue. / No longer a guess, / To clean up the mess, / A change that is long overdue. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the CHANGELOG.md to version 0.6.0, documenting a breaking change in the reusable-stale.yml workflow. The update replaces the generic days-before-stale and days-before-close inputs with four specific parameters to allow different timeouts for issues and pull requests. I have no feedback to provide.
Replace generic days-before-stale/days-before-close inputs with four per-type inputs so issues and PRs can have different cadences. PRs default to 60/21 (roughly 2x the issue grace period) since an open PR represents in-flight work, while issues stay at 30/14. BREAKING CHANGE: callers of reusable-stale.yml that set the old inputs must rename them to the new days-before-issue-* and days-before-pr-* variants.
apermo
force-pushed
the
feat/stale-per-type-timeouts
branch
from
506268e to
3df36f3
Compare
There was a problem hiding this comment.
Pull request overview
Updates the reusable “stale” GitHub workflow to support different stale/close timeouts for issues vs pull requests, and records the breaking change in the changelog.
Changes:
- Replace
days-before-stale/days-before-closewith four per-type inputs (days-before-issue-*,days-before-pr-*) inreusable-stale.yml. - Wire the new inputs through to
actions/stale@v10. - Add a
0.6.0CHANGELOG entry documenting the breaking input rename and new defaults.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| CHANGELOG.md | Documents the breaking change and new per-type stale/close defaults under 0.6.0. |
| .github/workflows/reusable-stale.yml | Introduces separate issue/PR stale and close inputs and passes them to actions/stale@v10. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Reflect the new per-type inputs introduced in 0.6.0 so callers do not copy/paste the removed days-before-stale/close names.
Bump CHANGELOG header to the actual release/merge date.
|
Released as v0.6.0 |
Summary
days-before-stale/days-before-closeinputs inreusable-stale.ymlwith four per-type inputs:days-before-issue-stale(30),days-before-issue-close(14),days-before-pr-stale(60),days-before-pr-close(21).## [0.6.0]. Localstale.ymlcaller is unaffected (uses defaults).Breaking change
Callers that pass the old
days-before-stale/days-before-closeinputs must rename them. No layered fallback is provided — the new inputs are required to be set explicitly only if the caller wants to override defaults.Test plan
actionlint .github/workflows/reusable-stale.yml— cleanstale.ymlrun and confirmactions/stale@v10logs the four per-type values