Reviewable changes
Reviewable changes
reviewable.io

Default review overlap strategy

 

New

  

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.

image.png

The repository default overrides personal defaults, but doesn't prevent a user from changing their overlap strategy for a given review.

Disposition handling changes

 

New

  

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: image.png

We hope these changes make your reviewing experience more pleasant! 🏖️🏝️

Support for maintain and triage permission levels

 

New

  

Reviewable now supports maintain and triage permissions.

The maintain permission has been added as an option to the discussion dismissal authority setting:

discussion_dismissal_authority.png

In addition, members with triage authority are now able to add and remove labels, reviewers, etc., directly from Reviewable.

Create code suggestion from current line

 

New

  

Single and multiline code suggestions can now be created from within a comment draft. No more manual copy/pasting!

Select multiple lines:

select_lines_from_draft_2.gif

Or double-click the button to insert the current line only:

select_line_from_draft_2.gif

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.

image.png

Vendored files support

 

New

  

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).

image.png

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!

Support for git spr (stacked pull requests)

 

New

  

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 😎 .

Ignoring comments from bots

 

  Upd  

  

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. 🥳

Code suggestions

 

New

  

You can now conveniently suggest changes when reviewing code:

image.png

And you get a nice, basic code editor when doing so, with syntax highlighting, automatic indents, and so on:

image.png

You can use the feature for code quotes, suggestions, or even just ad-hoc snippets to get the benefit of the code editor. And for those of you who like to lay out some options, there can even be multiple suggestions per comment. 😅

There are two major caveats:

  1. There's no click-to-accept functionality; you have to copy the suggestions into your code by hand.
  2. It doesn't interoperate with GitHub's code suggestions, because GitHub doesn't expose any API to do so.

We'll be working to further improve the feature (e.g., more compact diffing, jump to the original suggestion line) so please don't hesitate to share your ideas for how to make things even better!

Showing code coverage

 

New

  

Reviewable can now display code coverage annotations right in your diffs!

image.png

To take advantage of this feature you'll need to configure how to fetch coverage reports on your repository's settings page. We currently integrate natively with Codecov but can fetch from other report sources as well. Please get in touch if you need Reviewable to support another report format.

Jupyter Notebook reviews question

 

New

  

Hey folks, we're trying to figure out whether to put first-class support for reviewing Jupyter Notebooks on our roadmap and I was hoping you could chime in with a bit of data:

  1. Do you use Jupyter Notebook at your company?

  2. Do you review notebook changes, and if so what tool do you use to do it?

  3. Would adding support for reviewing fully rendered notebooks in Reviewable be of value to you?

  4. Roughly how many people need to review notebooks and what proportion already use Reviewable?

Thanks in advance for any light you can shed on this subject!