GitHub Actions... Where to begin? I have leveraged CI/CD pipelines for years through work but never stopped to understand what was going on during the process. As I embarked on the use of GitHub Actions I wanted to understand more about not only how to configure for use but also understand what is happening for each step. With no burning questions about GitHub Actions I figured the beginning was the best place to start!
It will be hard to fully talk about GitHub Actions without at least briefly articulating what CI/CD is. To start CI/CD stands for Continuous Integration / Continuous Delivery. Continuous Integration is the practice of frequently, and often automatically, integrating changes into a code base. This process consists of building the updated code, running applicable tests, and then merging the changes with the base. Or to use git terms merging the changes back into the main branch. Continuous Delivery, also referred to at times as Continuous deployment, is the process of releasing the changes. In continuous delivery this release would typically be to a non production environment, when using the term deployment it would typically mean a production environment. A full discussion on what CI/CD is and all that it entails probably deserves its own digest.
GitHub Actions can be used to manage CI/CD, however it is more than that. GitHub Actions allow you to run almost any sort of script or code to perform a task either on-demand, or on a trigger like code being pushed to a repository. GitHub Actions can be used to build and deploy code (CI/CD), manage automatic updates, or almost anything you can imagine.
GitHub has plentiful documentation including a “Learn GitHub Actions” section [4]. There are also an abundance of blog posts available with a quick Google Search of GitHub Actions. Without reinventing the wheel let’s take a look at some of the basics of GitHub Actions.
Most of this is covered in the “Quickstart” [5] for GitHub Actions, to get started you need to make sure that your repo can use Actions, in a person public repo this should be no issue but you can refer to the GitHubs plans for more precise details [6]. To create an action you will need to create a .github/workflows directory, this is where any action files will live. GitHub Actions are configured with yaml files (either .yml or .yaml extension). This file will contain the different steps for the action. You can refer to the “Quickstart” [5] guide for an example of what this yaml file needs to look like, but it consists of a name, a list of jobs with various steps, and a field to determine where the job should run.
GitHub Actions jobs can run on either GitHub hosted runners or self-hosted runners. Self-Hosted Runners will be covered in more detail later. GitHub provides servers for use as GitHub Hosted Runners. [7] These can be either ubuntu, windows, or macos for multiple different versions [8]. To use any runner reference the label in the ‘runs-on’ property of the action workflow yaml. Hosted actions run in self-contained VM’s that are used independently for each invocation.
While GitHub provides hosted runners, you can also use self-hosted runners in a “bring your own runner” set up. Self-Hosted runners allow you to have full control of the hardware, OS, and software on the runner. It also means that you are responsible for maintaining the server. Self-Hosted runners can be VM’s similar to the Hosted runners or could be in a container, a physical server, in the cloud, or on-premise. Hosted runners will need to have the GitHub Actions application installed. This software allows for the server to connect to GitHub and pick up the different runner jobs. Two important things with Self-Hosted Runners - the runner will be removed if not used at least once every 14 days, and the action software needs to stay up-to-date, if it is more than 30 days after the newest version then the software can’t receive jobs.
GitHub recently introduced Actions Runner Controller (ARC). [10] ARC is a Kubernetes operator to orchestrate and scale self-hosted runners. ARC allows managed scaling of containerized self-hosted runners.
While there are a number of actions available from GitHub and other 3rd parties it is also possible to create your own actions. [2]. These actions can be either a composite action, javascript, or docker container. Composite actions are shell script commands in the yaml file. javascript actions allow users to call javascript (or compiled typescript) to perform more complex actions. Docker container actions allow you to bundle your action similar to general use of containers. It is important to note that if you are using a containerized runner then Docker container actions likely will not work as expected when trying to reference local files.
All articles I either directly reference or found useful in my pursuit of understanding GitHub Actions!
[1]https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#runners
[2] https://docs.github.com/en/actions/creating-actions/about-custom-actions
[3] https://www.redhat.com/en/topics/devops/what-is-ci-cd
[4] https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
[5] https://docs.github.com/en/actions/quickstart
[6] https://docs.github.com/en/get-started/learning-about-github/githubs-plans