The workflow run at
https://github.com/zed-industries/zed/actions/runs/23557683707 succeeded
but threw some warnings for a rather-soon Node.js 20 deprecation (June
2nd).
Hence, this PR updates in that context mentioned workflows to newer
versions from which on the actions will use Node.js 24.
Namely, this updates
- `actions/checkout`
- `actions/create-github-app-token` and
- `peter-evans/create-pull-request`
to their latest version which includes said updates. As for their most
recent versions, all of these actions just updated their versions to
account for said deprecation.
Release Notes:
- N/A
More precisely, the name of the GitHub project board in question is
“Closed bugs with new comments”, and since GitHub seems to do the
closing and the commenting separately (and, crucially for this
automation, in that order) when the closer uses the “Close with comment”
functionality, we want to skip the comments added within 30 seconds
after the closing.
Release Notes:
- N/A
This moves some more of our CI jobs over to xtask and gh-workflow. This
primarily originated from the current GitHub actions outage to move
these actions over to Namespace runners. However, while I was at it I
decided to move these over to gh_workflow, as we benefit from sharing
more stuff across these files and less hacking around in YAML-files
directly.
Release Notes:
- N/A
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
