Building Github apps to fine-tune Github experience

Photo by Daniele Riggi on Unsplash

I am a front end engineer at Hiver. A few months ago, we were a small team of ~15 developers. Now we are a team of 35+ developers and growing. While constantly striving to engineer our product to be the best, we knew that the software engineering process had to be improvised. One of the important improvements we chose to do was to bring about best practices when we committed code into our git repo.

The problem

The Engineering team works on either the new features or the bugs/issues. We use a jira board to represent all the tasks.

Every task a developer works on must have a corresponding jira card providing more details on the task. The pull request must link to a jira card. This way we have a connection between the description of the task and the pull request(s).

Since we are a startup, the engineering team deals with a lot of ad hoc requests. Developers’ work and time must be accounted for. Sometimes, we will have to push changes to the code and we will not create a jira card. These changes account to a good amount of a developer’s time. By enforcing the above constraint, we want to make sure that a jira card is created for every pull request.

Create a github app

Github apps are a great way to customise Github environment. We chose to use Probot to create the Github app. In our example, we will be showing a Github app which will validate the description of the PR.

To create the probot app run one of the following commands.

npx create-robot-app app_name or yarn create-robot-app app_name

Running the above command will ask you meta-data for the app.

The app created will give you a folder structure like below

• index.js is where the code for the app will go.
• app.yml is the probot configuration file

The folder contains 2 dot files — env and env.example, which I will get back to in the next section. Rest is standard nodejs and git files.

Running the app

npm run dev

This will create a node.js server on port 3000. Navigate to localhost:3000 and follow the instructions to register the app.

Registering the app

Choose a unique name for the app and select the repo where you want to install the app. The repo you choose will be the one app will be listening to. You can find the app in settings>Integrations and services.

Check your .env file and it should have a WEBHOOK_PROXY_URL. This is the url of the smee service which will listen to the repo you have selected. You can verify by going to your account settings in Github>Developer settings>Github apps>your github app>Edit scroll down to webhook URL.

Listening to Github hooks

The probot is a node.js module which returns a function. The function receives a parameter app. This parameter can be used to listen to Github hooks.

Github hooks are actions you can do in Github. In our app, we are listening to pull request actions.

For example when a pull request is opened, edited and/or synchronized run the callbackhandlePREvents

The callback will receive one parameter context. The context object includes everything about the event that was triggered, and context.payload has the payload delivered by GitHub (from probot documentation). We use context object, in our example to verify if the PR has description adhering to our standards.

context.github can do almost everything users can do in a browser (apps are a first class actor in GitHub, equal to users). They can be used to add labels, reply to issues being reported, prevent merging of the branch etc.,

A code-e-thon way of learning

The developers at Hiver were asked to build an app like the above as a code-e-thon workshop. All the developers were made into groups of two (we obviously helped each other with the setup). It was an interesting exercise because of the following things.

Coding with another developer introduced us to pair programming. In that short period of time I found few benefits:

1. We distributed the work among the both of us and it made us think more holistically about what we are building. The product team usually thinks about the feature and developers are usually concerned about their own work. Here we thought of the whole app and how to get it done.
2. We articulated our solutions and this made us think about our approach and pushed us to deeper levels of understanding. If you can explain what you are doing, then you know what you are doing.
3. We wrote code which was read immediately. This is honestly the best benefit of pair programming, as this makes us write simple code. We also do not get carried away in our own thoughts as we need to collaborate constantly.

Hiver Engineering Team

Since it was a competition, we had to write test cases. We were scored based on code coverage and how well our description check was written. Basically, we “had to” take the Test Driven Development (TDD) approach to build the app. We used Travis to launch test cases and coverall to get the code coverage.

As you can see in the above gif, we used Travis and coverall. This is what me and teammate Sumit Majumdar scored.

I would tell I came 2nd but I am not 12 years old. Here are the code-e-thon winners.