PullReview: GitHub Status and others

This is an archive of blog post I wrote during my third venture (PullReview).

First of all, dear reader, I wish you Happy Holidays!

This blog post is about the last release of PullReview, that includes a few features before the end of the year:

  • Same Actions are grouped for Code Smell, Complexity, Design, and Duplication
  • Lower severity for issues detected in a test
  • Tweet your progress
  • New references & new contents
  • A few new rules for Code Style and Security
  • Notification via GitHub Status

Same Actions Grouped for some CategoriesπŸ”—

Actions are now grouped for the following categories: Code Smell, Complexity, Design, and Duplications (and of course Code Style and Documentation).

An example of actions grouped for some categories

It means that multiple occurrences of a same action is now grouped for those categories. For instance, if 24 times you should consider to refactor complex method, it is now grouped. PullReview will give you of course the locations of each occurrence.

For duplication, the grouping is slightly different as we group the duplication itself not the action. It means that if you have copy-pasted a snippet in two different files, it's one duplication, and one action to take: "Avoid copy/paste".


Lower severity for issues detected in a testπŸ”—

Even if tests are important, they don't require the same convention and quality level than production code. For instance, it's very common to not follow Don't-Repeat-Yourself (DRY) principle for tests because clarity and verbosity come first. For that reason, we have decreased the severity of issues detected in tests. As consequence, they will appear farther in your review and you will focus on what matters first: the code.


Tweet your progressπŸ”—

Each time you push a new commit on a branch, you'll get a new review. But PullReview will also track your progress since the last review. PullReview tell you how many issues you've fixed since the last review and how many you still have.

Screenshot of the "Tweet this" link.

When we fix a good bunch of issues, it's a victory that we might want to share. That's why we added a "Tweet this" link for Open Source project and let you tell the world you've cleaned it up with the help of PullReview.


New references & new contentsπŸ”—

As you know, we think it's not enough to underline the problem. It's important to explain you whys and hows. That's why we continue to improve the existing content, and add new ones.

We've added some new references: when you recently meet a problem, you don't read the same way a reference on the topic. Don't forget to share those you think worth to read, I'm sure that it will be appreciated by the other users.

We've also fixed some errors and typos, especially in code snippets.

We don't spoil them, and let you discover them.


A few new rules for Code Style and SecurityπŸ”—

Each time we can, new rules are added. This time, it's for Code Style and Security.

For Style, a lot of new rules are about spacing and blank lines, but also about global variables, parentheses, branching, etc. For Security, a bunch of new Ruby on Rails CVEs are now detected, especially those fixed by the last releases 3.2.16 and 4.0.2.

Again, we don't spoil them, and let you discover them :).


GitHub StatusπŸ”—

With GitHub Status, you will be directly notified in GitHub when a review is ready, and what's its status. This needs a quick setup in your account page:

GitHub Status setup: step 1.]

Simply find the option and enable it by clicking on the button.

GitHub Status setup: step 2.

Then, next time you push some code, you'll find on a GitHub Issue or PullRequest a status of your review attached to the corresponding commit:

  • Success when it's perfect GitHub Status: Perfect review.
  • Failure when there are issues to fix GitHub Status: Failure.
  • Error when there is at least one critical issue GitHub Status: Error.

If you use a Continuous Integration (e.g. Jenkins, TravisCI, CodeShip) and have enabled GitHub Status for it, it's possible that your CI will override the PullReview status as for the moment GitHub only show the last one.

When PullReview pushes a status, it will check if there is already one. If it's the case, it will merge its status with the last one. For instance, your CI has already pushed an Error before PullReview, PullReview will take it into account when it will push its status:

GitHub Status: CI failed.

That notification will allow you and your colleague to have a quick look of the situation by PullReview. I hope you will enjoy it, as we do.


Happy Holidays and have a great New Year!πŸ”—

I hope you'll spend it with family and friends in a warm place.

If you want to try PullReview, just sign up (it's free for Open Source project and there is a 31-days trial for paying plans).

If you have any questions about PullReview or anything else, you can contact us via:

  • our twitter account @8th_color
  • or via email.

Best Wishes!


If you have any comment, question, or feedback, please share them with me.


Atom feed icon Subscribe to the blog!