It’s been a while since the last PullReview news, so it’s time to give you some updates.

Over these past three months, we certainly haven’t been slacking and have brought in a bundle of features, for example:

Thanks to user bug reports, we’ve fixed several bugs and have made PullReview more robust. Thank you and please do continue to report any bugs you encounter. It helps a lot.

We’ve also carried out several upgrades: the usual security upgrades, Rails 4, and others.

We’re very proud that PullReview is of use to around 1000 Open Source projects. To list but the most well known: GitLab, Bundler and Cucumber-Rails.

As you may know, we’re still bootstrapping the company by offering our development services. If you need help (e.g. developing a Rails app, improving the dev workflow, maintaining a legacy app, learning how to refactor), we’d love to help you out. Just drop us an email!

Below, we’ll describe the new features one by one. We’ll finish off with some new features that we’re looking for a few testers for: Get reviews on your JavaScript, and Get reviews on Pull Requests created from a fork.


Share your reviews with your devmates

It was already possible to share a public review; when working with other developers on the same project, it can be useful to share a review: you can request help on a specific issue and can check the status of a PullRequest before reviewing it etc.

Now you can also share a private review with other team members. All they need to do is follow the repo as well. In fact, each team member can find all private reviews on branches they hadn’t actually contributed to on a dedicated page that can be visited by clicking on the button “Their reviews”.

Their Reviews


Never miss the chance to cover a code modification with a test

As you know, each time you commit, PullReview helps you not to miss adding a test to your branch.

Test infected!

But it’s a very simple rule, based on the ratio of modified sources and tests. It works most of the time but it’s not precise. What if PullReview could tell you exactly which modification you’re missing out on testing?

Test coverage

As a PullReview customer, we’d like to give you early access to this new feature we shipped in June for private repositories (that some of you have already discovered). This new feature will help you not to miss out on writing a test to cover a change you just made in your code. Basically, PullReview will also read your test coverage reports and tell you if you’re missing covering any code changes (the tests should be run somewhere, for instance by a CI provider). To enable it, go to your repository page and follow the setup instructions. Just click on the little list icon on the left of the lock icon. This will only appear for repositories that have been reviewed.

Test coverage setup


Personalised notifications

You can be notified by email when, for instance, a new review is ready. Before now, you didn’t have this choice. PullReview sent emails to your primary GitHub email address.

Perhaps your primary GitHub email address is a personal one and you’d prefer to receive reviews of your company repositories on your work email address? Whatever your reasons, you can now select another email address primarily used by PullReview to notify you. Just visit your account page and choose the email address.

Select your primary email

Perhaps you work for different organizations and don’t want to receive all notifications at the same email address? You can now set up notification routes that basically let you decide for one repo that you want to be notified on that HipChat room, for another organization that you want to be notified on that email address etc.

To set up your notification routes, go to your account page, scroll down to the Notifications pane, uncollapse it, and go to the Notification Center.

Notification Center

To add a route, click on the HipChat or Email button, fill in the form and save it.

Notification Center Setup


Know how your tech debt is evolving

When developing new features or fixing bugs day after day, you can miss the big picture of the state of your technical debt. How is it evolving over the time? Are we managing to keep it stable?

You’ll find the answer by visiting the analytics page of your integration branch by clicking on the analytics icon (top right of the list in the review page).

Analytics Button

There you’ll find trends for each category at the bottom of the analytics page.

Trends of your technical Debt


Filter a review for any given file

You’ve just pushed a few changes, reaching a good intermediary milestone. It seems a good time to clean up what has already been done. You look at the corresponding review on PullReview. You decide to start to add documentation, for instance. But you would like to do it file by file rather than jumping around.

It’s now possible to filter reviews for a given file:

  • Uncollapse the action, for instance “Add documentation to the following method”,
  • Click on “All issues for this file”

Filter out a review by file

You can also do it by yourself by adding the query ?file=<filepath> at the review URI.


Faster loading home and review pages

There’s nothing more frustrating than waiting for a webpage to load. It just looks like things have broken. We’ve had several loading performance issues with long reviews. We’ve made several improvements such as caching or partial loading and have managed to reduce the loading time for some large review pages from over one minute down to a few seconds. We’ve reached an acceptable thread-off for now. If you experience very slow web page loading, please let us know. There’s nothing better than real cases to improve performance.


Don’t be frustrated by conventions you don’t follow

In most cases, there is no right or wrong code style. What matters is to have and follow one. For instance, the usage of single or double quotes for string literal quotes.

We have observed two rules of the Ruby Style Guide followed by PullReview that are debatable: double vs. single quotes and Hash literal. As a consequence, people were inundated with reviews when they weren’t following them. Not very meaningful.

For that reason, PullReview can now detect when you aren’t following them and will inform you that it has ignored the rule.

Double quote rule automatically ignored


Don’t be afraid to use Cucumber, features are now recognized as tests

In addition to classic test and spec files, PullReview can now recognize your Cucumber features as tests.


You don’t need to be bothered by monthly invoices and payments - just subscribe once for the whole year

Who enjoys matching invoice to payment when doing the accounting? Because the answer to that is no one, we now offer a yearly subscription. It means just one payment and invoice per year. If you are interested in a yearly subscription, just send us an email.


Quickly spot files with the most critical issues in your integration branch

For an integration branch, PullReview reviews the whole code base. Depending on the project story, the resulting review could be quite long. So how could that be useful? So far, you can’t say where to start refactoring.

PullReview can now tell you what the hotspots are, i.e. files with the most critical problems.

Hotspots

For instance, on the master branch of Bundler, the hottest spot is definition.rb.

You’ll just get hotspots on new reviews for integration branch, not on old ones.


Be notified on your Slack room

To inform you when a review is ready, PullReview can send you an email, leave you a message in a HipChat room, or update the GitHub Status or badge. It can also do it now by leaving you a message in a Slack room.

Example of a Slack notification

Simply go to your account page and set up a new notification route.

Add a Slack notification


Get reviews on your JavaScript

When you develop a Rails app, you write the code in Ruby, but you can also write it in JavaScript. That’s why PullReview will also review your JavaScript code. This is still in Beta and we’re looking for more testers. If you’re interested in testing it, send us an email.


Get reviews on Pull Requests created from a fork

When you’re developing and maintaining an open source project, it takes a lot of time to review and check each PullRequest. Unfortunately, PullReview didn’t used to review PullRequests coming from a fork. This meant that a lot of open source maintainers couldn’t use PullReview to check them.

But PullReview can now review them. It’s in Beta and we’re looking for testers. If you have to check and review a lot of PullRequests coming from a fork and would like to test this new feature, just send us an email.


Happy Summer!

It’s summertime and time to take some days off.

Sunny days are back for most of us, always a great time to get out, spend time with friends and family, and leave codes behind you.

About a year ago, we launched the alpha version of PullReview. How time flies! Back then, there were about twenty users. There are now around a thousand of you! Thank you very much, we hope to continue to help you and others.

We’re here if you ever have any questions or need anything. Just drop us an email, we read all our messages personally.