-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
Fix or optimize issues workflow script #9522
Comments
I forgot to mention the manual workflow run: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch With this marker the workflow could be run manually and the maintainer can run the workflow over all issues once and then we are back to normal behaviour and not exactly 100 changes daily. |
Yea, I have probably missed a lots of real notifications because of this ... I just assumed that it was going to end one day. |
At this point the legacy issues have been processed by the updated workflow. Is it OK to close this issue now? |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
The workflow script for issues is suboptimal. I can say that without "probably" because the behaviour I am experiencing is, that every day in the morning (UTC+7) exactly 100 issues get locked/marked stale by the bot. Not more or less. This points to some form of limit. I was thinking to let it run its course and that the bot might someday be finished with all legacy issues, but then again, this is going on for weeks now. I think there might be a deeper issue.
Proposal 1: add manually workflow definition so the workflow can be run manually (if the issues touched per workflow run are limited somehow)
Proposal 2: optmise the setup:
In my opinion, this is the culprit, because the note of the bot that this issue is stale is an activity and this basically leaves us with 700 issues max before an already stale issue is admonished again. Set this to either something higher (30) or in combination with Proposal 3 to something like 10 or even higher
Proposal 3: close issues that are stale.
This lets the bot NEVER close issues that are stale, which leads to the weird behaviour described above. Let's set that to 7, so those issues can be closed. Also, the issue-stale and pr-stale days look very large to me. An issue is marked inactive after 7 days, but stale after 600 days?
Worst case scenario is that "disgruntled" developers and issue openers will complain about "their" issue being closed, but we can always say, that this is a hygienic way to keep the project management clean.
I somehow feel like the overall setup should be along the lines of something like this:
Sample: An issue is inactive after 30 days, stale after 45 and gets closed on day 59 or 60.
The text was updated successfully, but these errors were encountered: