randomize ordering when operations-per-run is in effect #692
Labels
Comments
|
I'm facing the same issue. I'm wondering if a PR would be accepted. A quick look at the code suggests that this could be the place to change it: https://github.com/actions/stale/blob/main/src/classes/issues-processor.ts#L534-L559 |
amcaplan
added a commit
to Shopify/shopify-cli
that referenced
this issue
Mar 22, 2022
It seems that 90 operations gives 23 issues, but then we'll end up repeatedly checking those same issues per actions/stale#692 So this ups the number to 200 which might be fast enough to at least tread water on our backlog. Hopefully if we can eventually get a randomized order, we can stale more quickly with fewer operations.
|
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days |
|
I am wondering if actually starting with the oldest PRs would fix this, without a need to randomize. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem
operations-per-run is handy to not run up against the github api rate-limiter, however, every time the action runs: it tries to process the same (default
30) issues that it did on the prior runs. This has the affect that the stale-bot is not making progress on large backlogs over time.The solution
Prefer to randomize the ordering, so that operations-per-run randomly picks which issues to process. This will have the effect of eventually (randomly) seeing every issue, instead of always only looking at the first (or last) 30 issues by default provided by the operations-per-run and ascending config settings. Thanks.
The text was updated successfully, but these errors were encountered: