Using self-hosted runners in GitHub actions

Before getting into this, please go through the blog below to learn about the foundational concepts of GitHub actions.

Getting started with Continuous integration using GitHub actions

Let’s learn about runners first.

Runners:

Runners are the virtual servers that execute the jobs specified in the workflow. It can clone the repository, install the required software, and run the commands and other processes that can help continuous integration. There are two types of runners supported by GitHub actions

1. GitHub-hosted runners
2. Self-hosted runners

GitHub-hosted runners:

As the name implies, these runners are hosted and managed by GitHub in its virtual environment. It contains a set of tools, packages and configurations leveraged by GitHub actions. The VMs are available in Ubuntu Linux, Windows and macOS operating systems which can be utilized for testing the code in different environments. Also, maintenance and upgrades of the VMs are taken care by GitHub. The steps involved when a workflow is getting triggered are as follows,

1. New VM is automatically provisioned for a job
2. All the steps get executed on that VM
3. After job completion, the provisioned VM is automatically decommissioned

GitHub-hosted runners comes with the below configuration:

For Windows and Linux virtual machines:

• 2-core CPU
• 7 GB of RAM memory
• 14 GB of SSD disk space

For macOS virtual machines:

• 3-core CPU
• 14 GB of RAM memory
• 14 GB of SSD disk space

Self-hosted runners:

As mentioned above, GitHub provides fixed configuration for the managed runners. Some of the workloads might require a more powerful configuration. This is where self-hosted runners are useful as they allow us to provision VMs with custom configuration. For example, we can use AWS EC2 c5.2xlarge for compute-intensive workloads and EC2 r5.4xlarge instances for workloads that process large data sets in memory.

If the workflow requires less power than GitHub-hosted runners, we can consider running cheaper instances on any cloud provider as a self-hosted runner. In this way, we can save cost.

Also, we can set up an EC2 runner in any subnet of our Virtual private cloud(VPC), which enables communication with any other private resources in the VPC. For example, the runner can access an RDS instance in a private subnet.

Please note that we are responsible for the cost and maintenance of the runners.

Enough theory, let’s play!

• Kindly go through the previous blog mentioned at the top for the initial set-up.
• As per the GitHub documentation

We recommend that you only use self-hosted runners with private repositories. This is because forks of your repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

• Go to repository → Settings → Actions → Runners

• Select New self-hosted runner option → Choose runner image → Choose architecture

• After selection, follow the steps suggested by GitHub to download, configure and use the self-hosted runner. Please make sure you have the necessary permission to execute those steps. It should show the below-given message for a successful setup

• Commit and push any changes to the repository
• Check the Actions tab from the GitHub page to get the status of workflows
• Check the command line of the self-hosted runner, and the build started there

Troubleshooting:

1. Make sure you have the necessary permissions to set up and configure the runners. For example, in a windows machine, the execution policies might block the external commands
2. Sometimes the workflow will not trigger due to an outage very rarely. You can check the GitHub Status here
3. Check out the official documentation here, About self-hosted runners

Thanks for reading. Happy learning :)