GitHub – where all the Actions are

In my previous blog, I explained that Git is the tool for source code version control and GitHub is the service that hosts the code repositories. In the early days, GitHub was also primarily focussed on version control but over the past decade it has evolved to reflect the requirements of teams collaborating to build software systems. Today, GitHub serves some 40 million users and hosts 100 million repos. Most of the world’s open source community uses GitHub.

GitHub isn’t just for Open Source

GitHub’s open source contribution model is an essential tool for internal IT teams working on inner source as opposed to open source projects. GitHub InnerSource code is maintained in private repositories. InnerSource is simply using best practices and methodologies from open source development in a confined corporate environment. As I will explore later, some of the more recent enhancements to GitHub, allow for the customisation and automation of repos around CI/CD workflows which are now very much part of the way internal DevOps teams work.

Recent GitHub developments

Microsoft Visual Studio has become one of the most popular IDEs for open source development, with support for languages most commonly used for open soiurce projects. Microsoft has also been a front runner in building collaboration features into its dev tools, such as Visual Studio Team Systems. The acquistion of GitHub last October has allowed Microsoft to build out a complete collaboration solution for developers working on both inner and open source projects. In this blog and the next, I will be taking a closer look at some of the new features that have been added to GitHub recently. I’ll start with GitHub Actions.

GitHub Actions

The purpose of Actions is to allow teams to customise and automate their GitHub repos. This is about extending GitHub itself to respond to events that effect the repo in the way you choose. Actions builds on GitHub’s ability to listen to webhooks on events.

Webhooks are user-defined HTTP callbacks which can be triggered by an event, such as pushing code to a repo or perhaps a blog comment being posted. The source site makes an HTTP request to the URL configured for the webhook when the event occurs. An example of how this can be used is to build or set up integrations like GitHub Apps or OAuth Apps. These subscribe to certain events on GitHub.com which, when triggered, result in an HTTP POST payload being sent to the webhook’s URL. Other examples include using webhooks to update an external issue tracker, trigger CI builds, update a backup mirror or deploy to your production server. Webhooks can be installed per organisation or specific repository. They can also be configured to allow control over which events are responded to. This can be useful for limiting the number of HTTP requests to the server. The list of subscribed events can be updated through the API or UI at anytime. By default, webhooks are only subscribed to push events. If you subscribe to the issues event, you’ll receive payloads every time an issue is opened, closed or labelled.

Webhooks are not without drawbacks though and the purpose of Actions is to overcome these. Subscribing to webhooks requires hardware which has to be provisioned and kept online with all the maintenance and cost overheads that goes with that. Actions removes this requirement. GitHub provides your own computing resource in the cloud for building custom tooling and applications to extend GitHub. Actions went into beta about a year ago and has been well received. As an example, we can now build bots for automating things in the respository. Github has a marketplace for Actions that you can take advantage of to extend your workflow automation.

It wasn’t long before dev teams started to use Actions as a CI build service which it wasn’t really designed for. In response to this, GitHub has added support for CI/CD. This allows you to integrate custom functionality and build/test, CI/CD workflows across Linux, Windows and macOS platforms – all hosted in the cloud. If you’re an iOS developer, there is support for Apple hardware and Xcode. GitHub is the only repo hosting service that offers true CI/CD for macOS.

Working with Actions

YAML is pretty much standard these days for setting up the resources required for DevOps projects. GitHub uses YAML To configure the workflow for the language you wish to code with. To build/test against multiple versions of the language, you can create a matrix to store the version details and then cycle through the build for each version. The illustration below is fairly self explanatory. It illustrates how separate build and test artifacts are created for each of the different Node.js versions detailed in the matrix – versions 8, 10 and 12.

You can go multidimensional with this too by iterating through a set of specified OS platforms for each of the Node.js versions. The illustration below shows how to incorporate a further matrix to add three OS variants for each of the three Node.js versions. This will create 9 separate builds to cover each combination of language version for each OS platform – ‘ubuntu-latest’, ‘windows-latest’ and ‘macos-latest’.

Summary

A custom GitHub Action is a reusable piece of code which lives in a GitHub repository and will respond to a webhook. The GitHub Action is notified whenever a specified event takes place in the repository and you can build code around these events. This has many uses such as changing assignees or triggering a process, maybe when someone comments. The custom action can be part of your CI/CD workflow.