Github Actions ARM64 runner on Oracle Cloud

In this article I am going to explain how to setup self-hosted Github Actions (GHA) runner on Oracle Cloud Infrastructure (OCI) for free!

VM instance

Since some time OCI provides Linux ARM64 VMs in their Free Tier. They are based on Ampere Altra 80 and you could use up to 4 vCPU cores @ 2.8GHz, 6GB of RAM per vCPU, i.e. up to 24GB, 45GB of disk and 1Gbps network bandwidth. I’d say it is a quite good offer for free!

Assuming that you already have an account at Github let’s create an account at OCI:

• Go to https://www.oracle.com/cloud/free/ and click on “Start for free” button

• Enter all required details (email, username, password, address, etc.)

Note: the registration also requires Credit/Debit card details but it is not charged if you use the Free Tier service! For most OSS projects the Free Tier should be enough! If more power is needed you could create a second account at OCI or upgrade to a paid plan.

• Once you are ready with the registration sign in to OCI and create a new VM instance:

Create a VM instance (at the bottom)

• The important part here is to select Ampere as a shape and the number of vCPUs

Ampere shape with 4 vCPUs and 24GB RAM

Note: In the Free Tier plan you could have up to 4 VMs with 1 vCPU+6GB RAM, or less VMs with 2–4 vCPUs. In my case I created 1 VM with 4 vCPUs and 24GB RAM. Later we will setup several GHA runners on the same VM!

• At this step you could also select the Linux distro and version. I prefer Ubuntu but you could also choose Oracle Linux. For now there is no ARM64 image for CentOS.
• Before pressing the “Create” button don’t forget to give the instance a good name and to add SSH keys so that you could connect to it!

Runner

Once the VM instance is created we could start setting up the GHA runner(s)!

• Connect to the VM via SSH by using the “Public IP address” in the instance details in OCI UI
• Go to https://github.com/<USER>/<PROJECT>/settings/actions/runners and press “New self-hosted runner”

Add new self-hosted runner

• Download a Linux ARM64 runner

Download the runner agent

• Configure the runner

# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/<USER>/<PROJECT> --token <GHA_TOKEN>

Note: I’ve replaced the actual user/org name, project name and the token for security reasons. You should just copy them from the Github UI and paste them to the VM console.

The config script will ask you few questions. The second question is the most important one — how to name the runner. It is important if you plan to have more than one runners on the same VM — they should have unique names! By default the script offers the hostname as a name for the runner. For all other questions you could use the defaults.

# Last step, run it!
$ ./run.sh

After starting the runner agent it should appear in GitHub UI:

List of registered runners

Here we see that the runner is labeled with “self-hosted”, “linux” and “arm64” labels.

• Setup the runner as a service

./run.sh starts the process in the foreground. If your SSH connection drops or if the VM is restarted for some reason then the runner will be stopped. A better way is to start it as SystemD service!

sudo ./svc.sh install ubuntu

sudo ./svc.sh start

Note: if you use Oracle Linux then most probably the user will be something different than ubuntu!

Workflow

To make use of this runner you will need to update your project’s GHA workflow!

• To execute particular workflow or a job on ARM64 runner you should use

runs-on: [ARM64]

GHA will not execute the workflow/job on any other runner that is not labeled with “ARM64”

• To execute it on either x86_64 or ARM64 then use

runs-on: [ubuntu-latest, ARM64]

GHA will execute the workflow/job on the first available runner

• If you want to run the workflow/job on both architectures then you will have to use the matrix support

More runner instances

By design GHA executes one job at a time on a runner instance. That is, if you have more than one jobs in your workflow(s) and just one self-hosted runner then they will be executed consecutively!

Since our VM is powerful enough we could run more than one runners on it!

To setup a second runner you should untar the runner in a separate folder and use a different name for the runner at ./config.sh time. That’s it!

Security

There are some security concerns with GHA self-hosted runners for public repositories!

The problem is that an evil person could create a Pull Request that does something nasty on your VM.

To avoid this problem you have few options:

• Approve workflow runs for public forks

If you decide to use “Require approval for all outside collaborators” then a member of the Github project will have to approve the run of the workflow for any PR by a contributor. The contributor could still run the same workflows on his fork and see their status! Another option here is to use “Require approval for first-time contributors” — i.e. approve only the first PR by a contributor.

• Another solution to this problem is to use runner with security enhancements — https://github.com/actions/runner/pull/783.

It is created and maintained by Apache Airflow team. To make use of it you should download the runner from here and add some extra checks in your workflow YAML file.