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.
Window functions enable you to generate aggregations for ‘windows’ of your data. You define what the ‘window’ is by telling the database how to partition your data into frames around the current row, and perform aggregations across the rows in each frame.
Some example problems you could solve with window functions are:
After fielding a few package requests, I knew there had to be a better way. Stickler does all of its reviews inside docker containers with temporary filesystems. The solution seems simple enough. Before running each job find and install the additional packages required by the current repository. Then once the review is complete, docker could discard the container filesystem, leaving a pristine state for the next review. …
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.
In addition to OAuth integrations which have existed for almost a decade, GitHub now offers GitHub Applications. OAuth integrations allow an integration to request coarsely scoped access to a user’s account, and act as that user. For example, an OAuth integration cannot ask for write access to a few repositories. Instead it must ask for write access on all public and/or private repositories. This can make it harder to attract users as they don’t want to give you carte blanche with their data. …
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.
When I started building Stickler, the first implementation ran all linting tools on the host filesystem as a child process.
This design required having all linting tools installed on the host operating system. Getting all the linters to play together on the host operating system was challenging as a couple of them had esoteric and hard to build dependencies. This design could lead to secret information being accessed if someone managed to exploit a linter. A few supported linters allow users to provide their own rules. These linters posed the greatest risk and needed to have their custom rule capabilities disabled. I knew this was not an acceptable long term solution as it hobbled the product, and I wasn’t confident that all threats were mitigated. However, I wanted to make sure the product would be used before I invested in more complex solutions. …
In the next major release of CakePHP we’re going to be removing the
AuthComponent. This component and its helpers have been part of CakePHP since the 1.2 days, but their time has come to an end. Over the years,
AuthComponent has become a complex and difficult to extend piece of CakePHP. In its wake, we’re promoting two new plugins. First, cakephp/authentication will be replacing the identification parts of
AuthComponent while cakephp/authorization handles access control and permissions. These plugins are intended to be used together, but can be used individually. They can also be used outside of CakePHP applications thanks to PSR-7. The new authorization plugin makes answering questions like ‘can the current user edit this record?’ and ‘what records can the current user see?’ …
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.
Stickler CI is a software as a service application that automates a tedious part of code review; enforcing style and checking lint errors. It integrates with GitHub and checks each pull request for code style errors. Stickler CI will leave review comments when someone on your team makes a style error. This saves you time, as feedback on style errors is handled automatically, and your team doesn’t have to read through build reports to find whitespace errors. …
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.
Stickler CI is a software as a service application that automates the more tedious parts of code review; enforcing style and checking lint errors. It integrates with your GitHub repositories and checks each pull request for code style errors. Stickler CI will leave review comments when someone on your team makes a style error. …