PullReview: GitHub Status and others

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:

Best Wishes!





2 thoughts on “PullReview: GitHub Status and others

  1. Shannon

    This looks like a neat service! I can’t use it at the moment though because Github auth requires *private* repo read access that I can’t allow. Any chance of removing Private repo read/write?

    Reply
    1. toch Post author

      Hi Shannon,

      Thanks for sharing your concerns. We understand them.

      Any chance of removing Private repo read/write?

      Short Answer: Yes, it’s planned to request only public repo r/w for Free plan.

      Long Answer

      We started with requesting the highest permission because we’ve launched a first version where each new subscriber signed up by default for a Solo plan with a 31-days trial. But, it’s not necessary if you just want to use PullReview for your Open Source project. In that case, requesting r/w permission for public repo is enough.

      A word about the scope GitHub permission scheme. We don’t need the write permission, but there isn’t a way to request only read permission for now. If we want to retrieve a list of repo and offer a one click setup (allowing to easily add deploy key and webhook), we need to request the repo scope (public or private/public) that includes r/w permission.

      We think also about a manual setup for ppl that don’t want to give that write permission.

      If I understand you well, you’d like first to use PullReview for your public repo?

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>