Automating GitHub Projects at Kobai

This isn’t just about making life easier for our team—it’s about delivering faster, more reliable, and scalable solutions for our customers. By optimizing our internal workflows, we ensure that our customers get high-quality innovations with greater speed and precision.

Great work, Varun and team, for continuously pushing the boundaries of technical excellence! 👏

Continuous Integration has expanded over the course of my career. Originally, it was mostly only used to refer to the building processes of an application automatically, but now it’s taken on a larger role of generic automations as well as tools like GitHub Actions, Circle CI, Gitlab CI (a group of tools I affectionately call CI providers) become more commonplace. They allow for quick, serverless code execution and are highly configurable considering that they can all integrate with one of a DevOps engineer’s favourite tools: Docker.

In this article, we’ll be going over how we manage our slew of automation tasks with GitHub Actions, and a few examples of the really cool things we do with automatically, and this point, without even thinking about.

Path to finding a good CI Provider

Across my career I’ve worked with a lot of different CI providers (definitely all the big ones these days), and Kobai contributed to a lot of that, exposing me to CircleCI and GitHub Actions properly.

I have to say my personal favourite (and surprise surprise, the one we use today) is GitHub Actions. I found that it has the most versatility and functionality while still being comprehensive enough. My favourite feature of it is the reusable actions, and you’ll see why in a little bit. Also the cheapest for our providers.

CircleCI was ok, but definitely lacks in functionality and support. We’d have multiple times where we were at a standstill because our CI wasn’t functioning because of an outage. That tied with the fact that to create reusable orbs, you need a lot of overhead, and lack of path-level filtering on triggers, it was obvious that it was time to move.

When we first started to move to GitHub Actions, I was skeptical that it would be cheaper. I was definitely a big fan of how much better it was to write good quality automations with, but in due time, as we moved all of our repositories over, we found that we were able to run all of our CI workflows within free tier limits!

Except for one repo. Our frontend Docker image requires a fairly large amount of memory to build (needs to run on an 8x32) so we used the GitHub Hosted large runners, which was still costing us cents to the dollar vs CircleCI.

Reusability

Remember earlier when I said my favourite feature of GitHub Actions was the reusable workflow feature? Well that’s because at Kobai we’ve built a “net” of reusable workflows which we use for anything that’s repeated, which works very well when we have multiple different repositories that have very similar workflows CI, project management or otherwise.

First, we define a reusable workflow in an “agnostic” or “neutral” location, so in our case we have a management repository that we put a lot of these into. This is by convention, but the main benefit we get out of this is that one workflow doesn’t balloon with a bunch of very specific code.

name: Say Something

on:
  workflow_call:
    inputs: 
      message: 
        description: Message to say
        type: string
        required: true

jobs:
  send-message:
    runs-on: ubuntu-latest
    steps: 
     - name: Set cluster based on namespace
       run: echo $

When we have our workflow defined we can then go about and create an instance of it. The neat part of reusable workflows is that you can reference a GitHub ref so it makes testing really easy. I’ll let the official docs take it over from here.

Once we’ve tested it, we just copy our implementation YAML file to wherever else we need it. And when we go to make edits to the workflow, we only need to edit it in the one “neutral” instance of it rather than everywhere. Nice and DRY!

Kobai Automation Image

It wouldn’t be appropriate to talk about how we keep things reusable without touching on our automation image. This image is a fairly basic image that just contains all of the tools that we use in our CI pipelines and other automation tasks. I’d urge each and every one of you to define one of these for your own projects and organizations, as it cuts down minutes on your CI pipelines by having all your tools preinstalled and configured.

Project Automation

Using our reusable workflow strategy, we created several project automation tools that help us manage the lifecycle of our GitHub Issues with respect to our GitHub Projects. I won’t bore you with the implementation details of this, as it’s a lot of GraphQL that will take some time to parse through but here’s the gist of it:

1. Issues-2-projects — Automatically adds issues to our GitHub Project when the issue is created.
2. Issues-2-in-progress — Automatically moves issues into the “In Progress” state when a branch is created to start working on the issue.
3. Issues-2-pending-pr — Automatically moves issues into the “Pending PR” state when a pull request is opened for the issue.
4. Batman — our orphan issue tracker, automatically adopts issues into the next release if they’re not already associated with one, on issue completion. This makes sure that issues are properly documented with a release so we’re able to look back and be certain of what releases introduced what features, at a conceptual level.

Automating Security Patching with Snyk

When you create software that is used by others, you need to be extremely on the ball with your vulnerability patching. How we do this at Kobai is using a tool called Snyk, with automatic patching. Snyk automatically detects vulnerabilities and creates pull requests for review by the relevant engineering team. Once the PR is merged we’re able to continue our typical release process to cut a patch release. As you’d expect, we have a GitHub Actions workflow that automatically adds it to our GitHub Projects as well, to make sure we don’t miss it in any other releases!

As everyone knows, not all security vulnerabilities are created equally. Some require immediate attention, while others are less pressing. We treat critical and high severity issues as immediate needs for patches and cut release appropriately. Our automations go through and detect the severity and automatically assign the relevant type releases and make sure that even the GitHub Issues reflect the priority!

Conclusion

That sums up a good chunk of our automations. We’ve got a lot more under the hood to manage our CI, but I’ll leave that for another article as this one is already getting quite large. From GitHub’s GraphQL API to reusable workflows, we make the most of the platform to drive our CI costs down and manage our GitHub Projects.

Feel free to follow us on LinkedIn or check out our website.