chore(ci): revisit stale issues automation #1341
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of your changes
As described in #1340, the current automation for stale issues was broken. While in the issue I incorrectly assumed that this was stalebot's fault, this was not the case.
The repo actually had two different automations for the same purpose: one was the aforementioned stalebot and the other was a workflow called
stale-issues.yml
that is run every day at midnight. The latter was the one that was broken.Additionally, while looking into stalebot, I found out that it's now unmaintained and deprecated, so in this PR I am removing its configuration from the repo.
The stale workflow was previously running using the
aws-actions/stale-issue-cleanup
action, however after comparing it with the officialactions/stale
the differences were minimal and I decided to go with the official one.As mentioned, the workflow is expected to run once a day at midnight. It's not clear which timezone this refers to, given that the cron feature doesn't support timezones, however based on previous executions this seems to be between midnight and 1AM CET, which is good enough.
The workflow operates only on issues and only on issues explicitly labeled as
need-more-information
andstatus/discussing
. This should limit the amount of issues closed automatically given that maintainers should use these two labels in conjunction to denote that an issue is being discussed but more information is needed from the person who opened it.If no interaction is made (aka the info that was missing is not provided), the workflow will mark the issue as stale and apply the
status/pending-close-response-required
label. The workflow will also leave a comment that says:If 7 more days pass, the issue will finally be closed as
not_planned
(close reason) and labeled asstatus/rejected
, with a comment:If instead the issue is interacted with within a week, the label will be removed and the issue stops being stale.
Issues that haven't yet been triaged (labeled as
triage
) or that have a clear status as indicated by the labels:status/confirmed
,status/blocked
,status/on-hold
,status/completed
, are excluded by the automation and left open.PRs should be excluded by this workflow. The documentation around this is a bit unclear, but based on a comment in the project's issue it seems that setting a negative amount of days to the PR config of the action avoids marking any PR as stale.
How to verify this change
Once merged, check that there are no issues in the workflow syntax. Then a day after check the workflow execution to see that there were no runtime errors.
Related issues, RFCs
Issue number: #1340
Checklist
Breaking change checklist
Is it a breaking change?: NO
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.