chore: a stalebot to close inactive issues and PRs #29134
Conversation
steveluscher
force-pushed
the
stalebot-the-return
branch
3 times, most recently
from
0e094a2 to
ad2a9fe
Compare
There was a problem hiding this comment.
The debug logs for this action are lovely. See a debug run, here: https://github.com/solana-labs/solana/actions/runs/3635088973/jobs/6133857914
| # 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. |
There was a problem hiding this comment.
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.
| # 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 |
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.
| close-issue-message: "" # Leave no comment when closing | ||
| close-pr-message: "" # Leave no comment when closing |
There was a problem hiding this comment.
I feel less strongly about this one as I do about stale-issue-message and stale-pr-message. You could make the case that an email should be sent when the thing is ultimately closed. My preference is for the bot to be silent, but deadly.
| days-before-issue-stale: 7 | ||
| days-before-pr-stale: 14 | ||
| days-before-close: 7 |
There was a problem hiding this comment.
This was replicated from the old config at .github/stale.yml.
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!
…let's start with the old configuration
But isn't the deleted stale.yml the old configuration? If not, do you know where to find said old configuration?
There was a problem hiding this comment.
There was a problem hiding this comment.
and if I'm reading this right, days-before-pr-stale should probably be 7 to match the old config
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.
| days-before-issue-stale: 7 | ||
| days-before-pr-stale: 14 | ||
| days-before-close: 7 | ||
| 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-issue-labels: blocked,do-not-close,feature-gate,security | ||
| exempt-pr-labels: blocked,do-not-close,feature-gate,security |
There was a problem hiding this comment.
These are copied from the old .github/stale.yml workflow. I added do-not-close as a way to exempt an issue/PR from stalebot's clutches.
| # No actual changes get made in debug-only mode, so we can raise the operations ceiling. | ||
| operations-per-run: ${{ github.event_name == 'pull_request' && 2000 || 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.
| # 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.
steveluscher
force-pushed
the
stalebot-the-return
branch
2 times, most recently
from
f2452c4 to
b11156e
Compare
|
This whole effort might be dead in the water if what this person claims is true: actions/stale#792 Seems that the overhead of checking a large number of issues can exhaust your API operations rate limit before you have examined all of the open issues/PRs in a repository of this size. Maybe we can pay money for a slightly higher rate limit? |
steveluscher
force-pushed
the
stalebot-the-return
branch
from
b11156e to
19e486d
Compare
…stalebot I got this wrong in #29134. The original config set this at 365 days, not 7.
…stalebot (solana-labs#29157) I got this wrong in solana-labs#29134. The original config set this at 365 days, not 7.
…stalebot (solana-labs#29157) I got this wrong in solana-labs#29134. The original config set this at 365 days, not 7.
Problem
We just crested 1K issues, and stalebot is nowhere in sight. Let's add stalebot back in, gradually, to get abandoned issues and PRs under control.
Summary of Changes
I will annotate all of the changes inline. Comment under those annotations.
Test plan
Here's a debug run: https://github.com/solana-labs/solana/actions/runs/3635088973/jobs/6133857914
Fixes #29093.