Introducing Stickler-CI

I’d like to introduce a project I’ve been working on over the past few months. Stickler-CI helps automate the tedious process of ensuring coding standards are followed during pull requests. Like many teams, FreshBooks uses pull requests as a way to solicit feedback from other developers, ensure consistent coding practices and catch bugs before they can cause real problems. I noticed my team was spending a significant amount of time adding comments for coding standards violations. This felt like a waste of people’s time. While we had jenkins builds that failed when people added new lint errors people were consistently scrambling to fix the lint builds as they were caught by surprise. While, we had ways to run the linting tools locally, people rarely ran them. Both of these problems led me to building a solution.

I started to work on lint-review as a way to make lint errors visible in code reviews. lint-review has proven to be very effective at FreshBooks. However, it is a bit arduous to get up and running. Stickler-CI adapts lint-review into a hosted service that is easier and friendlier to use. Instead of a CI build that fails after merging your code, Stickler-CI posts lint errors as line comments on your pull requests. This greatly reduces the feedback loop, and lets developers focus on reviewing the intent and logic in the modified code instead of worrying about whether or not whitespace and braces match your styleguide.

How does it work?

After authorizing https://stickler-ci.com to your github account, you can enable Stickler-CI on any public repositories you have admin privileges on – private repository support will be added in the future. Once enabled, Stickler-CI will listen for new/updated pull requests on your project and apply the linting tools you’ve setup. There are reasonable defaults built-in, but you can customize the linting rules through a yaml file. An example .stickler.yml for a PHP, Javascript and CSS project could look like:

Show Plain Text
  1. linters:
  2.  # Enable PHPCS using the PSR2 standard.
  3.   phpcs:
  4.     standard: PSR2
  5.     extensions: '.php'
  6.   # Use jscs to check javascript files.
  7.   jscs:
  8.  # Use css-lint to check CSS files.
  9.   csslint:
  10.     ignore: 'box-model,ids'
  11. branches:
  12.    # Ignore pull requests to the `2.x` branch
  13.     ignore: ['2.x']

The Stickler-CI documentation has the full list of supported linters, and all the configuration options if you are interested in learning more. Stickler-CI is still in an early stage, and I’d love to hear any feedback you have at all about what could be improved, or if there are linters/languages you’d like to see supported.

Comments

Awesome!

Xu on 9/12/16

Thanks for nice post :) An example .stickler.yml for a PHP, Javascript and CSS project could look like:

noor on 6/1/17

Have your say: