Remove label from stale issues on comment event #2903
Conversation
|
Triggering the action by comment isn't a good idea, since it is processing the same issues as with the cronjob, which could lead to run into the rate limit if to many comments are done:
Screenshots are from those two runs: |
Reverts #2903 @mauwii has a point here. It looks like triggering on a comment results in an action for each of the stale issues, even ones that have been previously dealt with. I'd like to revert this back to the original behavior of running once every time the cron job executes. What's the original motivation for having more frequent labeling of the issues?
|
Yes, I was fully aware of the number of issues being processed with this change. Does it actually lead to hitting any rate limits, or is this a hypothetical? @mauwii can you suggest an improvement to this by getting it to process only specific issues, instead of rejecting it outright? |
|
With the latest change, the limit would already be hit with two comments to issues / hour (which would already have been done). And since the 500 operations-per-run still not process all of the issues, I am not sure if it needs to be raised again. I also had no chance to suggest anything since it was merged before I even saw the PR ... |
I found it to be a chore to remove labels manually in order to "un-stale" issues. This is contrary to the bot message which says commenting should remove "stale" status. On the current
cronschedule, there may be a delay of up to 24 hours before the label is removed. This PR will trigger the workflow on issue comments in addition to the schedule.Also adds a condition to not run this job on PRs (Github treats issues and PRs equivalently in this respect), and rewords the messages for clarity.