The participants panel helps you manage the review process efficiently by providing a centralized view of all participants, including their roles, status, and relevant statistics. You can also take actions related to users, with more coming soon!
You can now avoid re-reviews of code after a rebase with no conflicts, though you'll need a custom completion condition to do so.
There's a new baseChangesOnly flag available to custom completion conditions. This flag is set for each revision of a file, and indicates whether all visible changes can be cleanly attributed to an edit in the base branch that was integrated into the pull request. The flag's value must first be computed in a client, so it won't be available to the condition as soon as the commits are pushed but the condition will be re-executed once the flag is ready.
We have a new sample condition that ignores base-only changes when computing completion. You can adopt it as-is, or crib from it to integrate the relevant logic into your existing one.
One subtlety about detecting base changes is which revision should be used for comparison. While a file revision's action ('modified', 'renamed', etc.) is always determined against the immediately preceding revision, base change detection uses the matched "prior revision" as its reference. This is often the immediately preceding one, but when rebasing multiple commits in a review following "review each commit" style Reviewable will do its best to match up each "new" commit to its semantic antecedent. You can see this in the review UI, with arcs connecting file revisions when you hover over them.
We don't surface these details about prior revisions in the condition's input data structure but our algorithm is fairly robust and biased towards needing strong evidence for a match, so false positive baseChangesOnly flags should be extremely rare.
Let us know how this new feature works for you!
Now you can explore a discussion's history one comment at a time in addition to showing the entire thread. We also revamped the UI surrounding the options to show/hide all comments in a discussion, file, or all files so you can quickly find what you are looking for and experience faster, more effective reviews!
You can now set a per-repository default review overlap strategy. This can be useful if, for example, your team's workflow requires each reviewer to review every file, and you don't want to bother the reviewers with setting their own defaults.
The repository default overrides personal defaults, but doesn't prevent a user from changing their overlap strategy for a given review.
We originally launched the discussion disposition system some four years ago, and while it's held up pretty well we've also learned a thing or two in the interim. Today, we made a number of changes to make things run more smoothly, and not all of them are backwards compatible.
First, your default disposition when creating a new discussion as the PR author will be set to ⭘ Discussing rather than ⛔︎ Blocking. While the latter was consistent with the default disposition for reviewer-initiated discussions, it was almost never the right choice for author-initiated ones and many authors ended up unnecessarily blocking their own reviews. You can still override the defaults for any of these situations, of course.
Next, we're making some changes to disposition keywords, which let you change your disposition based on a comment's first word. FYI will now always select 🛈 Informing, and BTW always select ⭘ Discussing, whereas before their effect was context-dependent. We're also removing OK, as in practice it tends to be used to start all kinds of messages, not just approving ones.
⚠️ If you have a draft comment started with an older version of Reviewable, and you edit it with the new one, your disposition will be reset to follow the new rules — even if you didn't edit the keyword itself. ⚠️ To help you notice this we added a small flashing effect when a keyword disposition takes effect.
Finally, if you don't want to use disposition keywords at all, you can now disable them in your disposition settings panel, accessible via a small gear icon in the top-right corner of any disposition dropdown:
We hope these changes make your reviewing experience more pleasant! 🏖️🏝️
Reviewable now supports maintain and triage permissions.
The maintain permission has been added as an option to the discussion dismissal authority setting:
In addition, members with triage authority are now able to add and remove labels, reviewers, etc., directly from Reviewable.
Single and multiline code suggestions can now be created from within a comment draft. No more manual copy/pasting!
Select multiple lines:
Or double-click the button to insert the current line only:
Bonus: We also added a command palette for taking actions when you make a manual selection. You can quote the selection to start a suggestion or copy the selection to the clipboard.
In some environments it's traditional to commit third-party code into the repository, but you usually don't want to review changes to them. Reviewable will now recognize these so-called "vendored" files, put them into a new group that's collapsed by default, and exclude them from file rename matching (to reduce PR analysis time).
We have some basic heuristics for automatically detecting vendored files based on path but please let us know if we should add new rules for your favorite language! You can also take manual control of the process and mark files as vendored or not in your custom completion condition.
Here's to more meaningful reviews!
Reviewable now supports git spr. Stacking pull requests is a convenient way to isolate the scope of pull requests. Spr is a tool used for stacking pull requests that creates a stack of PRs, making sure all PRs in the stack meet a set of user defined criteria before merging them together.
Reviewable will track PRs in the stack and link to the relevant reviews in the top review discussion for convenience. When a stacked PR is merged using spr, children PRs don't get merged, but closed. Reviewable will track the status of these PRs and update the review state to reflect whether it's actually been merged into the head of stack 😎 .
When a user posts a comment (whether via Reviewable or GiHub), we automatically snapshot all revisions to ensure that the comment's context is preserved. This can lead to a mess, though, if you're taking your time pushing commits to a PR before asking for a review and a bot (perhaps CI?) is posting comments as you go. There can be dozens of snapshotted revisions by the time you invite a reviewer! 😅
To avoid this situation, Reviewable now attempts to detect whether a comment was posted by a bot and avoids snapshotting revisions in that case. We detect bots by checking whether the username ends with [bot] (for GitHub Apps bots) or -bot, or the display name ends with (bot). If you have a favorite bot account changing its username could be tricky, but it should be easy to append (bot) to its name since that oughtn't be referenced anywhere. 🥳
