Repository navigation
Add custom actions to close and lock stale issues - #6241
Conversation
| ignoredLabels: debugger | ||
| closeDays: 14 | ||
| closeComment: "This issue has been closed automatically because it needs more information and has not had recent activity." | ||
| pingDays: 80 |
There was a problem hiding this comment.
I don't understand the 80 for ping vs 14 for close here. Won't the issue be closed and locked already?
There was a problem hiding this comment.
StaleCloser.ts is fairly brief, so should be easy to decipher. The issue is not closed if pingDays is set and if the last commenter is not specified in additionalTeam and does not have write or admin access to the repo (or is a bot). If there is an assignee, a comment will be posted to ping them instead (once per pingDays).
There was a problem hiding this comment.
But we'd be pinging after the issue is closed? 80 > 60
There was a problem hiding this comment.
No, the issue would not be closed if the last comment was made by a user, and not us (as we may not have seen their comment, and the issue may be on our plate, not theirs). Instead, after pingDays, the assignee is pinged. After an issue is closed, no-one will be pinged. The StaleCloser action only queries for issues that are: "is:open is:unlocked"... Though, the code as written does appear to assume pingDays will be greater than closeDays, as the initial query is based on the closeDays value.
There was a problem hiding this comment.
Got it. So "closeDays" is for when it's assigned to us and "pingDays" is for when it's assigned to them.
There was a problem hiding this comment.
If you are using the term 'assigned' loosely, then yes. If you are using it to refer to assigning the issue using the 'assignees' field, then no. closeDays is for when we were the last ones to comment on the issue. Otherwise, if a user was the last to comment, it doesn't get closed, and IF there is an assignee they are pinged.
…into coleng/add_actions
|
Andrew Wang (@WardenGnaw) Which of the actions should use the debugger label filter? |
|
None for now. I can modify the YAML later to add support for the debugger ones. |
5 participants
Custom actions, based on the locker and needs-more-info-closer actions here: https://github.com/microsoft/vscode-github-triage-actions
Much of this code was copied from vscode's actions, and does not align with the coding style of cpptools. Since this is not part of cpptools itself, changing a lot of code to adjust the style doesn't seem particularly important to me, unless others disagree.
There are 2 actions:
Locker - Locks a closed issue after it has been closed for a period of time, and there has been no activity for a period of time.
StaleCloser - If an issue had no activity for more than a specific period of time, it is either closed (with a message to the user), or, optionally, if there is an assignee and the last commenter was not someone with write or admin permissions to the repo (or a member of 'additionalTeam'), a comment is added which pings both the author and assignee. If there is no assignee, no one is pinged. (There is not a good way to know who to ping, since the last commenter was not a team member. Alternatively, I could scan all comments for all team members, and ping them all, or pick one?). Optionally, a specific label can be applied to the issue when closed.
I've added a common base class which generically handles filtering candidate issues based on labels (to include/exclude, or 'no:label'), milestone (singular required milestone, a set of milestones to exclude, or 'no:milestone'), minimum number of votes, or maximum number of votes.
The following workflows are based on the StaleCloser action: question-closer, more-info-needed-closer, feature-request-closer
The feature-request-closer is based on our initial idea for how it would work: It will close an inactive Feature Request with less than a minimum number of votes. It will not be locked, so users may continue to up-vote it.
Feel free to suggest policy changes, changes to the comment messages, etc..
I've manually tested these in a test repo, using delays of 0 days (immediate) and running them directly via the Actions tab. But, we should still look very closely at these, as they will be making bulk changes to our issues.
... It occurs to me that I may be able to combine these 2 actions into a single action, by adding params to indicates whether candidate issues should be filtered by open/closed/locked and whether the result of the operation should be to open/close/lock the issue. That would make a singular generic data-driven action...