chore: finetune stale action

[HonkingGoose]

What would you like Renovate to be able to do?

The stale action ran, but "runs out of steam" before dealing with all issues, as we can see by the "warning" it raises at the end of the log output: Warning: Reached max number of operations to process. Exiting.

We now have a log that we can look at to see how the action works on our repo.
It seems to go through the repository issues, most recent issues first, and for each issue do multiple things to determine if that issue fits the criteria or not.

Also I noticed in the "Action" tab of the renovate repository that the name of the action is too long to fit on the screen.
We might want to reduce the name length, if this bothers us?

Did you already have any implementation ideas?

I've asked the maintainer of actions/stale about what the operations-per-run property does exactly so that I know if we should increase that number or not, or if we should increase the CRON frequency, or do something else.
I don't want to cause timeouts on our other GitHub Actions by running the stale action in a excessive way, as that might cause problems for our primary process.

Once I know what operations-per-run means, I'll make a PR to improve the stale action some more. 😄

[rarkins]

If the next night it runs it finds another 5 or 10, then I think we're ok. Once this stale bot reaches a steady state, 30 could be enough per day. Will be good to hear what the maintainer says.

[HonkingGoose]

I have copy/pasted my questions and the maintainers response in full so we're not missing any context:

My questions to the maintainer

I still don't understand what the operations-per-run property means (even after reading the new text this PR adds).

The default setting for the operations-per-run property is 30. But what does that number mean?

• Will the action only check 30 issues each time?
• Or will the action only comment or close 30 issues per run?
• Something else.

It's not clear to me if the current configuration examples are meant for repos with say 30 open issues, or also for repos with 700+ open issues?

Could we maybe add some more to this PR, like:

• Explain the limits on amount of open issues when following the defaults.
• Explain if you need to increase frequency of action run via CRON, OR if you need to increase operations-per-run OR maybe even increase both frequency and operations.
• Examples of config for small/medium/large open issues repositories.

Maintainers response

@HonkingGoose each time the action needs to interact with the GitHub API to alter the project content (CRUD) and to process the issues and PRs like adding the stale label, at some point on huge projects and based also on the other actions present in the project you could hit the GitHub API limit.
So in order to have a "limit" for one to avoid consuming all the possible API calls and also to let's say "set up a viable limit" this option was created.
The default value is very low for each kind of project IMO and obviously the "right" limit is totally dependent of the project and the stale config.
The CRON frequency should be set IMO to run one time per day, it's the more logical setup.
Obviously having a better doc is a thing and this is one of my primary goal for the next PR (once all my current one are landed).

Impressions after 2 stale runs

The first run did not have enough operations to finish the job fully:

[#5037] Skipping this issue because it doesn't have all the required labels
[#5039] Found this issue last updated 2021-01-12T09:55:08Z
[#5039] The option "onlyLabels" was specified to only processed the issues and pull requests with all those labels (2)
[#5039] Skipping this issue because it doesn't have all the required labels
Warning: Reached max number of operations to process. Exiting.

The second run did finish, and even was nice enough to print out the full result:

---
Statistics
Processed issues/PRs: 764
Operations performed: 30
Fetched issues: 9
Fetched issues events: 6
Fetched issues comments: 6
---
No more issues found to process. Exiting.

Can we get by with current settings?

Looking at the results from the second run, it seems that 30 operations is about enough to process 764 issues/PRs.
This is about what we have open now (722 issues + 43 PRs= 765).

The maintainer said that the CRON frequency should stay at once a day, as that is the more logical setup.
So the only thing really that we can change is the operations-per-run value, and the time at which we run the action.

I think we're right on the limit of what the current operations-per-run value can handle (run 1 failed, run 2 succeeds).
So we should probably increase the limit slightly (maybe to 40).

[rarkins]

@HonkingGoose do we have open issues matching the criteria that the action is currently missing, even on the second run?

i.e. is the concern that the current limits are not enough, or that they might soon be not enough?

[HonkingGoose]

The concern is that the current limits are just about enough for what we have right now.

It seems that operations-per-run set to 30 allows the action to process 764 issues/PRs.
We currently have 725 issues + 42 PRs which makes 767 in total.
I guess we're right on the limit of what 30 operations-per-run will allow us to process.

But we should also consider that we might need those GitHub Action CRUD quota for other things as well.
So if we increase the limit, we should do it in small steps and monitor for errors in other actions.

[rarkins]

I think increasing it to 40 is quite fine if that's enough to address it for now

[HonkingGoose]

764 issues/PRs in 30 operations-per-run points: 25,4 issues/PRs per point.
If it scales linearly, we can estimate that 40 operations x 25,4 issues/prs processed = 1016 issues/PRs processed in total.

So we should be good for about 1000 total open issues/PRs then. 😄

[renovate-release]

🎉 This issue has been resolved in version 24.89.3 🎉

The release is available on:

• GitHub release
• 24.89.3

Your semantic-release bot 📦🚀