0665569d26
Crank Stalebot's operations limit up to a level that should handle all issues
...
This thing seems to have been humming along at 300 in the dead zone between NA night and Europe morning. Let's see if it can handle the entire corpus.
2022-12-28 19:46:41 -08:00
ec5e5dbffa
Double the Stalebot operations limit
2022-12-27 07:49:53 -08:00
7429df5176
Increase the Stalebot operations limit by another 50%.
2022-12-26 16:03:46 -08:00
b619b0d33f
Increase Stalebot's operation consumption limit by another 50%
2022-12-23 21:53:19 -08:00
65ff61cfc8
Increase Stalebot operations limit by another 50%
2022-12-20 09:12:53 -08:00
9a82368dc9
Increase stalebot operations limit by 50%
...
We have to increase this until either it can handle 1000 issues in a single run, or we hit the GitHub API operations limit.
2022-12-19 23:03:40 -08:00
92c90271ab
Remove `start-date` config from Stalebot
...
This doesn't actually do what I thought it did. The `start-date` config doesn't make stalebot start from a certain date forward, it makes tasks older than that date immune to being closed.
This means I'm going to just have to find a way to raise the GitHub API operations limit to be able to handle more tasks, or wait until enough have been closed that it fits within our current limit.
2022-12-19 23:02:32 -08:00
8380bf027d
chore: correct the name of the STALEBOT_START_DATE_RFC_2822 variable ( #29191 )
...
Oops. Changed this in the repository, but failed to update it in code.
Note to self: land this _after_ 8:00UTC Dec 10
2022-12-17 09:38:42 -08:00
6b2275574f
chore: correct days before an issue in GitHub is considered stale by stalebot ( #29157 )
...
I got this wrong in #29134 . The original config set this at 365 days, not 7.
2022-12-08 14:39:13 -08:00
8a0a578465
chore: a stalebot to close inactive issues and PRs ( #29134 )
2022-12-08 14:17:21 -08:00
Steven Luscher