Are you doing GitHub checks?
There’s literally no excuse — in 15 minutes I got a running check for each PR in our main branch. And it’s free!
What’s GitHub check? It’s a way to automate some checks against your source code. Like does it build? Does it pass tests? Does it pass linting? Do all the tedious tasks that computers are good at and people easily miss.
The project we use checks for is an Angular single page application. It uses Node.js and TypeScript, Jest for unit testing and TSlint for catching stuff like fit and fdescribe and console.log and similar code mistakenly checked in.
The goal of the check was to have the build, unit tests and linting run before the PR(pull request) has been merged. So it would catch a broken build before it ends up in everyone’s checked out code. Or a broken test. Or a debugger checked in.
And if code review is done then the reviewer would be able to concentrate on the more high-level stuff and be certain the computer did the boring part.
Cool, so how do we do that?
The project was being built using a Jenkins job and for a few days, I struggled to make Jenkins do something on the event of a new PR. Couldn’t do it. I am more used to Azure DevOps (formerly VSTS) and I decided to try it out. Went to https://github.com/marketplace?category=continuous-integration&query=azure and searched for ‘azure’:
Note: If Azure Pipelines has been already installed you’ll see the screen shown towards the end of the article.*
Given this script — any change to master will trigger the build. That may be what we need in some cases — continuous integration for example. In our case, we need something else. More on that in a bit. First — click on the “Save and run” button on the right which will let you choose whether to commit to master or start a pull request with the azure-pipelines.yml file. Either works and you end up with the pipeline configuration as code checked-in along with the code it’s going to build! Neat. Here’s my first build.
Next, let’s change the script azure-pipelines.yml to only trigger on pull request:
Notice that we explicitly stop the build on check-ins and merges. And only trigger it on PR-s to master. This will only do the checks. At work, we do our actual continuous integration builds orchestrated by Jenkins on AWS machines.
Start a PR
After we start a PR we can see that in a few seconds a check is initiated:
Broken lint
And when we break a test, or the build or one of our linting rules we will see some immediate feedback. For example, I forgot an fit call in a PR #3:
I really like this feedback!
…this check is executed only on PR and does not affect any other continuous integration or deployment you might have
To summarize, this check is executed only on PR and does not affect any other continuous integration or deployment you might have. It aims at providing quick feedback.
This is the Azure project link. It’s public — go take a look.
And the GitHub repo https://github.com/gparlakov/devops-demo.
About that free part up there at the start of the article. I know it’s hard to believe, but here are the facts:
- for public repos — like this one — unlimited minutes with 10 parallel jobs
- for private repos — 1 job and 1800 minutes a month. Like the project, I described at the beginning. We are a team of 5 and actively contributing and do around 1000 minutes per month.
*If the pipeline app is preinstalled on your repo you’ll see:
Alternatively, if starting a brand new project:
- take a look at yo team
- if just creating the GitHub repo and have already installed the Azure Pipelines GitHub app you can add it immediately at repo create time:
