This was a big one, with multiple releases to production, as we are finalizing the Enterprise release!
Comment Authoring and Reviewing Changes
Thanks to you too!
When a new comment starts with
thanks, we now mark it as an "informing" comment, along with our previous magic keywords of FYI and Tip (case insensitive, of course!) You can find all our magic keywords in the docs for .
We also fixed a bug where we would highlight these magic keywords when they had no effect (such as the main discussion thread, where there are no dispositions).
Let me just fix it, already
When you just want to fix it without opening up your editor again (or maybe you're on your smartphone), now you can pick GitHub's edit UI from the user settings!
We'd like to improve this further by embedding the ability to edit files, or apply code suggestions you or others have made, so please let us know how you would like us to expose those features. You can view the .
Bots (not) in the participants panel
Many of you have noticed the new participants panel, and thank you for the feedback! Some of you have bots that frequently add comments, such as coverage notifications or URL's to other services, and you mentioned that having them show up as participants was annoying, especially since their row never added any value.
We fixed that! Now, any bots, based on their usernames starting or ending in bot, -bot, or [bot], will be excluded. If you have another way to detect if a given GitHub user is a bot, please let us know!
More reviewers in the panel
If you wrote a comment in one of the top-level discussions of a code review, then previously you were marked as a lurker in the panel. Now any and all comments make you a reviewer, as many of you expected.
Handling more renames
One of our magic features is handling renamed files, even across rebases, and taking comments along for the ride. We fixed a rare issue when a file was changed multiple times during the life of a single review with comments from multiple names.
When you are only drafting comments
If you're writing comments on a PR, but you weren't already a requested reviewer, your role icon is a green eye since, once you publish the comments, you will be marked as a reviewer.
And when your whole PR is a draft
Sometimes GitHub's API changes its mind on which field indicates a PR is a draft or not, so now we check both places, so your draft PR's show up correctly more consistently.
There's a little-used feature for tracking when a review status changed, and that's to receive a webhook. We natively built Slack support into it, but a few users have wished to customize the text, as well as connect it to their own systems.
We've added a ton of new data to the webhook payload, and you can check out our docs for . We use this feature internally to assign the notification to the engineer that is blocking the current code review, to reduce wait times and noise at the same time.
Completion Condition Environment
We finally upgraded the runtime environment for our completion conditions to NodeJS 18. If you were running into any problems with NodeJS compatibility, you should be able to use all the newer API's now.
The Obligatory Bugfixes and Performance Improvement Section
Don't you hate it when you go to update your favorite app and all it says is "Bugfixes and performance improvements"? Worst yet is when there are new bugs or the app is slower, and now you have no idea who's to blame, you or the developers.
Well, sorry, but we fixed some bugs and made some performance improvements, too. They're a fact of life. We also moved some code around and made things a little more readable for ourselves, but we're hoping you won't notice any of that.