Introduction to GitHub Actions and the macOS Runner

Today I want to write about GitHub Actions - one of the most powerful tools we have access to. In the next few articles I want to go through the journey of what Github actions are, the pros and cons of the Github provided macOS runner, using your own self-hosted runner, and lastly setting up a Cilicon virtual machine.

Some of the sections will be surface level, as I probably can assume if you're in the world of using Github and development then you're probably aware of setting up or using actions.

What are Github actions

GitHub Actions allow you to create custom workflows that are triggered by events such as code pushes or pull requests.

Think of it as a if this, then that (IFTTT) but for your code base. It is kind of endless in the things you can achieve with action workflows, but you can also get sucked into building a mammoth project for yourself just to run a simple task.

What I've used it for

I have a few repos that publish to Github pages. That in itself is an action that will take the directory and use it as it's public access for the domain. But that one's fairly straightforward, I don't even think I wrote it and was a verbatim copy-paste.

The more frequent actions I use are markdown linters, broken link checkers, or unsafe urls. Again these aren't mission critical actions, but they do allow me to use Github actions to take the command line tools our of the user's hands and into a centralised location.

It also means there is only one set of rules for everyone, and with Github you can enforce the action's success in order to merge - which is something I really like for static site generators.

I've also used it to compile my Github npm packages and push them to npmjs without having to worry about different commands, logins, or configurations.

I think my biggest Github action project was using it on the Exposure VIC API repo. This is where I took the COVID-19 exposure sites in Victoria, geo-located the addresses, and merged them into a new JSON file. It also meant that I could run this on a CRON schedule and have the data compiling without having to manually run it.

macOS runners

Where does the macOS runner fit into all of this? Well, most scripts can be run from the default ubuntu-latest runner. You'd install node, install a few packages, and run it against your code.

But when you're building a project that is purely macOS based you need to run it on a macOS machine. With a macOS runner, this means you can use this ephemeral machine to run workflows that are compatible with macOS, such as those written in Swift or Objective-C.

Essentially anything you can run on a macOS (from the Terminal), you can run on a macOS runner. This means many of the popular languages and frameworks, including Python, Ruby, and JavaScript can all be run from a macOS instance.

Why a macOS runner on Github

Now, I know what you're thinking, "Why should I use the macOS runner, rather than just running my workflows on my own computer?" The answer - as alluded to earlier - is simple, consistency.

The macOS runner provides a stable and consistent environment for running your workflows.

This can be especially useful when running workflows that involve building and testing code, as it ensures that your workflows will run consistently across different environments.

Shortcomings of macOS runners

I'm not going to get too detailed since I'll cover this in the next post more in-depth, but like any tool, the macOS runner has limitations.

For starters, you can only run macOS compatible workflows, and they have to be installed from the command line. You can't run Windows or Linux only actions within the macOS runner.

There is also a surcharge for using the Github macOS runner - and not a small one, it's a fairly steep jump.

I think I can understand the number of use case for a macOS runner are vastly smaller than Linux. Many of the tools we use to validate would be written in a Node package or Bash script. For the most times you'd use a macOS runner, you could probably do it in Linux for a fraction of the cost.

But I'll cover this next time.

Conclusion

At the end of the day, the macOS runner is a powerful tool that can be used to automate tasks in your software development workflow.

It offers a stable and consistent environment for running your workflows, as well as advanced features that can help improve the performance and efficiency of your workflows.

However, it's important to consider its limitations and whether it's the best option for your specific use case.

In the next articles, we'll dive deeper into the pros and cons of using the macOS runner, as well as alternative options that you can use to automate your tasks. Stay tuned, and as always, happy coding!

Resources