Learning GitHub Actions

Chapter 5. Runners

Regardless of what functionality you implement with GitHub Actions, there has to be a place to execute that functionality—a virtual or physical system with enough resources to process a job, and one that is configured to interact with the Actions control plane as it dispatches jobs. In Actions terminology, the systems where jobs in a workflow are executed are referred to as runners.

At a high level, you have two choices for the runner systems. You can use default systems provided by GitHub or you can configure, host, and use your own. I’ll explore both options in this chapter along with their key attributes, usage, and pros and cons. I’ll start by looking at the systems that GitHub automatically provides by default.

GitHub-Hosted Runners

The runners provided by GitHub are the simplest and easiest way to execute jobs in workflows. Every GitHub-hosted runner is created as a new virtual machine (VM) with your choice of Ubuntu Linux, Windows Server, or macOS as the operating system. An advantage of using the GitHub-hosted runners is that GitHub takes care of the needed/required upgrades and maintenance for the VMs.

When executing workflows with these runners, no additional setup or configuration is required for each job beyond the simple runner declarations, such as runs-on: ubuntu-latest.

These labels in the workflow’s YAML cause GitHub to provision and start a virtual runner system with a particular operating system and environment for a given job. Table 5-1 ...