-
Notifications
You must be signed in to change notification settings - Fork 353
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
Not handling a repo with many PRs and many stale PRs in a useful manner #975
Comments
Hello @msorens, thanks for your input, we are starting to investigate the issue |
this issue relates to #792 |
Hello @msorens , can you please try to run the action on the main branch to make sure it solves the problem?
|
I would, but I no longer have access to the repositories I was using at the time. 😞 |
Ok, then i close the issue, because the repated PR is merged, but please feel free to reopen it or create new one in case if the problem still exists |
We are seeing that the resume doesn't seem to be working - it keeps just reprocessing the same 30 issues (our ops-per-run) over and over with an action that runs on Mondays and Thursdays. https://github.com/prusa3d/Prusa-Firmware/blob/MK3/.github/workflows/stale.yml Edit: I see now there hasn't been a release since this fix was merged. When can we expect one? |
+1 for release, we are struggling with this too @dsame |
Description:
The handling of a repo with many PRs (on the order of a hundred PRs or so) and many stale PRs seems poor. Upon hooking up the
stale
action, expecting to get a lot of PRs tagged as stale, it tagged a dozen or so PRs as stale. So far, so good. Figured it stopped due to theoperations-per-run
limit and throttling issues discussed in the docs. But upon running it again—expecting it to tag an additional set of PRs—it did apparently nothing.From the docs, "If you choose not to increase the limit, you might end up with unprocessed issues or pull requests after a stale action run." But what that statement does not say is that that will be true forever. Meaning, the
stale
action does not take history into account at all. It always just starts from the newest PR, and runs until it hits theoperations-per-run
limit. I am not sure if that means it stops when it has reviewed a certain number of PRs or when it has tagged a certain number of PRs as stale, but either way that makes its not very useful for a large repo with a large number of PRs.The potential workaround, of course, is to increase the
operations-per-run
, but given the warnings in the docs that does not bode well.Action version:
v8
Platform:
Runner type:
Repro steps:
Set up a repo with a hundred PRs
Expected behavior:
Prior runs should be taken into account so that, if running the
stale
action multiple times, it will eventually review all PRs.Actual behavior:
No history is accounted for; new scans always review the same set of PRs until the limit is reached.
The text was updated successfully, but these errors were encountered: