ci: close stale issues and pull requests

[UlisesGascon]

Adds a daily actions/stale workflow (pinned to v11.0.0), modelled on the one in nodejs/security-wg: issues and pull requests with no activity for 30 days get the stale label and a comment, and are closed after another 30 days unless there is activity or the label is removed.

Exempt labels: security-release, release (issues and PRs), plus help wanted and good first issue (issues), so tracked work is never auto-closed.

[coveralls]

coverage: 99.739%. remained the same — chore/stale-workflow into main

[bjohansebas]

Hmm, I don’t oppose this, you’re the captain after all 😄, but I’d personally prefer that we go through the existing issues and review them, then either close them manually or get the PRs merged. It’s been a while since I’ve reviewed them, so I’m not sure what issues are still open, but we can gradually close them as the PRs get merged. Most of them are probably still valid PRs; people just don’t always have the time to dedicate to them, so they end up going stale.

[krzysdz]

Marking issues as stale and closing them usually just shows that nobody had time or cared¹ to triage them. I think that this would make sense only for issues/PRs labelled awaiting more info ². Otherwise it'll just frustrate people and lead to situations like podman-container-tools/buildah#6611 (comment).

An issue that nobody had time to look into may still be valid. A PR with no activity can be picked up later by a maintainer if the author does not respond. Closing things just because they're old is like complaining that some dependencies have not received updates in a long time (even if there is nothing to update).

Personally, I don't think I've ever checked multer's issues and pull requests. I have never used it and there seems to be some activity here (security advisories), so I thought that someone is taking care of it. Although I'm against stale bots in general, I won't oppose this strongly, because I don't really help here either.

Footnotes

1. Recently I've been ignoring a significant part of PRs (and issues) created using AI in other repos, because it's just no fun, bots (and possibly human meat proxies) don't understand things, there are lots of duplicates (I often close duplicates if skimming the title is enough to recognise them), usefulness of some PRs is dubious (though formatting-only PRs have been opened by people since forever), descriptions are super long, extremely verbose and sometimes partially wrong, and these things are just way harder to review/understand/triage than real human communication. ↩

2. Labelled, so somebody must have checked it and decided that it requires the author's attention - something is not clear and/or it can't be reproduced. ↩

[UlisesGascon]

My original approach was to aggressive TBH and was focus on exclusion labels. Also the side effect of closing issues/prs without at least one human review was not desired. Agree that just auto-closing what has being "awaiting more info" is the logical automation we need. The never-stale label remains as an escape hatch 👍

[krzysdz]

GitHub may not run scheduled workflows during high load, especially at the start of every hour (and I assume that midnight may have the highest number of scheduled tasks).

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped.

I think there shouldn't be any problems if this is skipped once in a while, but it's good to remember that there is such problem with GH Actions.

[krzysdz]

The actions/stale action sometimes has to delete cache (it's used to preserve state, because issues and PRs are processed in batches) and this requires the actions: write permission.

More information can be found in actions/stale#1248