While looking at performance data for Stickler CI, I noticed that some reviews spent a surprising amount of time talking to the GitHub API. While Stickler CI spending a large amount of time talking to GitHub isn’t that shocking, what caught my interest was the amount of time spent fetching modified files.

Up until now if a build failed, or didn’t run correctly on stickler-ci you had to rely on the build status to figure out what to try. While this mostly works when jobs outright fail, it isn’t great for jobs that succeed with the wrong or unexpected results. If you got incorrect or unexpected results, debugging what was going on was a tedious and time consuming process. Thankfully, those days are behind us now.

Recently I shipped a new feature to Stickler CI that enables users to extend Javascript and Python builds with additional packages. Maintaining review tool dependencies can be a drain on your team’s time. Stickler CI helps solve this problem, but used to come with a tradeoff of not being able to fully customize your style rules.

With the release of CakePHP 3.7.0 quickly approaching, I wanted to help validate the release candidates by upgrading a few of my sites and seeing how much work it was. I’d like to share the process I followed for my upgrades on Stickler CI, this site and a few others I maintain.

I recently built a GitHub Application for Stickler CI and wanted to share what I learned along the way. While the documentation for GitHub Applications is pretty good there were a few things I struggled with.

Stickler CI is a software as a service application that automates a tedious part of code review; enforcing consistent style and preventing lint errors. By integrating with GitHub, Stickler checks each pull request for style errors and post review comments when an error is found. This helps your team align on coding standards and provide more valuable feedback. Stickler is free for public repositories; private repositories require a paid plan.

In this three part series, I’m going to cover the evolution of Stickler CI in the past 2 years from the initial prototype to the present day. This specific article will cover how I brought Stickler CI from an unprofitable project to a revenue generating product and the growing pains surrounding that journey.

In this three part series, I’m going to cover the evolution of Stickler CI in the past 2 years from the initial prototype to the present day. This specific article will cover how I built the initial prototype and then added paid plans.