chore: a stalebot to close inactive issues and PRs #29134
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,43 @@ | ||
| name: "Manage stale issues and PRs" | ||
| on: | ||
| # Chosen to be just before London wakes up and way past San Francisco's bedtime. | ||
| schedule: | ||
| - cron: "0 8 * * 1-5" # This is in UTC. | ||
| # Do a dry-run (debug-only: true) whenever this workflow itself is changed. | ||
| pull_request: | ||
| paths: | ||
| - .github/workflows/manage-stale-issues-and-prs.yml | ||
| types: | ||
| - opened | ||
| - synchronize | ||
|
Comment on lines
+6
to
+12
There was a problem hiding this comment. Because we also run this workflow on pull requests – but only pull requests that change the workflow file itself – we can easily test out tweaks to the config. |
||
|
|
||
| permissions: | ||
| issues: write | ||
| pull-requests: write | ||
|
|
||
| jobs: | ||
| stale: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/stale@v6 | ||
| with: | ||
| ascending: true # Spend API operations budget on older, more-likely-to-get-closed issues first | ||
| close-issue-message: "" # Leave no comment when closing | ||
| close-pr-message: "" # Leave no comment when closing | ||
|
Comment on lines
+25
to
+26
There was a problem hiding this comment. I feel less strongly about this one as I do about |
||
| days-before-issue-stale: 7 | ||
| days-before-pr-stale: 14 | ||
| days-before-close: 7 | ||
|
Comment on lines
+27
to
+29
There was a problem hiding this comment. This was replicated from the old config at There was a problem hiding this comment. It used to be a year before stale-bot marked issues as stale. Here's one example: #16270 and you can see them all at https://github.com/solana-labs/solana/issues?q=is%3Aissue+is%3Aclosed+label%3Astale+ Maybe a year is too much, but let's start with the old configuration There was a problem hiding this comment. Oh, oops. I didn't see this before landing it. I'll update it!
But isn't the deleted There was a problem hiding this comment. There was a problem hiding this comment. and if I'm reading this right, edit: oops, apparently GH defaults to "you want to do a review, right?" post merge, so this wasn't submitted There was a problem hiding this comment. Ah. I was following the recommendation here, which I gave preference over the olde config. |
||
| debug-only: ${{ github.event_name == 'pull_request' }} # Dry-run when true. | ||
|
There was a problem hiding this comment. When running on a PR, the bot logs to the workflow logs without actually taking any actions. |
||
| exempt-all-milestones: true # Milestones can sometimes last a month, so exempt issues attached to a milestone. | ||
| exempt-issue-labels: blocked,do-not-close,feature-gate,security | ||
| exempt-pr-labels: blocked,do-not-close,feature-gate,security | ||
|
Comment on lines
+32
to
+33
There was a problem hiding this comment. These are copied from the old |
||
| # No actual changes get made in debug-only mode, so we can raise the operations ceiling. | ||
| operations-per-run: ${{ github.event_name == 'pull_request' && 100 || 30}} | ||
| stale-issue-label: stale | ||
| stale-issue-message: "" # Leave no comment when marking as stale | ||
|
There was a problem hiding this comment. I don't think becoming stale is a comment-worthy event, nor should it send an email. My position is that stalebot shouldn't be your reminders app; if you think you will need reminding about an open issue, you can set a reminder in a way that makes sense for you. |
||
| stale-pr-label: stale | ||
| stale-pr-message: "" # Leave no comment when marking as stale | ||
| # Time immemorial when in debug-only mode (ie. on pull requests). | ||
| # `STALEBOT_START_DATE` otherwise. | ||
| # You can use this as a killswitch by setting `STALEBOT_START_DATE` in the far future. | ||
| start-date: ${{ github.event_name == 'pull_request' && '1970-01-01T00:00:00Z' || secrets.STALEBOT_START_DATE }} # ISO 8601 or RFC 2822 | ||
|
There was a problem hiding this comment. This is a strategy for introducing this thing gradually. I will set myself a reminder to back this off slowly, so that we don't end up with every notification, all at once. |
||
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.
If emails are to be sent at all, I figured it best to send them when as few people as possible are likely to be interrupted/nerdsniped by them.