-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Increase stale issue time & enhance stale bot config #6924
Conversation
This adjusts the durations before issues and PRs are considered stale, and also before they're closed.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6924 +/- ##
=======================================
Coverage 97.86% 97.86%
=======================================
Files 1084 1084
Lines 94290 94299 +9
=======================================
+ Hits 92280 92289 +9
Misses 2010 2010 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but please confirm the cron-started workflow is run as non-debug.
type: boolean | ||
default: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, the debug mode is not in effect when this get started on cron schedule, can you please confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right; that setting around lines 10-11 is only for when the workflow is invoked manually, via workflow_dispatch. Otherwise, on cron schedule, the value of inputs.debug is never set and is therefore an empty string. In the workflow body, the debug-only
flag for actions/stale defaults to false
:
debug-only: ${{inputs.debug || false}}
My thinking is that it's rare for someone to want to invoke it manually, and when they do, it's mostly likely because they're debugging something, so the natural default in that case is to turn it on. Plus, it has the advantage of erring on the side of caution, by requiring confirmation for taking action.
days-before-stale: 90 | ||
days-before-close: 60 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should flip these. The issue / PR should become stale before closed.
NVM - after reading how those values work, sorry about the noise.
Without a name, the name shown in the GitHub UI for workflow execution is "stale", which is uninformative and ambiguous.
Until we have time to revisit the auto-closing policy (issue #6866), we decided we could increase the duration before issues and PRs are marked as stale and closed. This PR changes the durations to 90 days before marking as stale and 60 days before closing. It also adds a couple of enhancements: