Learn about the foundational concepts of GitHub actions.
Before getting into this, please go through the blog below to learn about the foundational concepts of GitHub actions.
Let’s learn about runners first.
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
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,
GitHub-hosted runners comes with the below configuration:
For Windows and Linux virtual machines:
For macOS virtual machines:
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!
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.
name: Node.js CI on: push: branches: [ "main" ] pull_request: branches: [ "main" ] jobs: build: runs-on: [self-hosted, linux, x64] steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v2 with: node-version: '14.x' - run: npm install - run: npm test
Thanks for reading. Happy learning :)