Remove the attempts to have these issues land in the same 'inbox' (the
existing project board for triage). Since they're closed, the automated
workflow of the project board will move them to the 'Closed'
column/status even with the API call specifically moving them to
'Incoming' instead. It is what it is, we'll have a separate project
board for this.
Also:
- don't look at comments on PRs
- don't freak out if the issue has no type
- add a permissions block as a defensive measure (in case someone adds
secrets.GITHUB_TOKEN later)
- add a timeout to avoid hanging out for six hours or whatever the
default is
- add some logging.
Release Notes:
- N/A
Since the project board to which the closed bugs with new comments are
added might have an automated workflow for moving closed issues to the
"Done" status, we need to override the status to ensure the bugs are
actually surfaced to the team and not buried in "Done".
Release Notes:
- N/A
Sometimes bugs come back or are not fixed all the way. We want to
preserve the context of the issue we've closed prematurely so instead of
always making people open a new github issue in this case we want to be
able to notice if someone* comments on a closed bug and decide what to
do about it.
Before:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → Maybe someone sees the notification about it, maybe
not; maybe they see it but forget to act on it right away and it's lost.
After:
Bug is closed → A user can again/still reproduce it on a new version and
leaves a comment → The issue is added to a project board where it's
visible until someone makes a call about it (maybe the comment was “oh
my glob i'm so happy this was fixed” and no action is needed, or maybe
the issue must be reopened as a regression).
*Someone in this case means (1) not a bot, (2) not a member of staff.
Release Notes:
- N/A
Lena