Some basic concepts on GitHub’s CI/CD Platform
Ever heard of GitHub Actions? Maybe you haven’t, but I’m sure you’ve heard of DevOps, CI/CD, and a bunch of other buzzwords going around lately. In this article, I want to unveil the mystery around GitHub’s continuous integration and continuous delivery platform. I know it can be daunting going through the documentation and trying to make sense of it.
Hopefully, by the end of it, you will have some understanding of how the platform works, and you won’t have to pretend you understand your release manager during your daily meetings.
Before I lose your attention with some technical lingo, let’s try to understand what we are talking about with an analogy. We can define GitHub Actions as a toolbox filled with building blocks that enable us to assemble a small factory where some bots will perform some actions for us.
I rather build my factory once than manually go over the same list of actions for every new pull request!
So,… how skilled are our little bots? It’s up to you! Some simple tasks you could let them do are, checking the formatting of your code, deploying the latest features, or labelling your pull requests. But in order for them to know what to do, they will need a script or some instructions.
The main building blocks of this script are the following:
- Events — It refers to the activity that will trigger a flow in your repository. For example, an activity can originate from GitHub when someone creates a pull request or pushes a commit to a repository.
- Workflows — A workflow is a configurable process that will run one or more jobs. You can find them in the format of YAML files in your repository.
- Jobs — A job is a set of steps in a workflow. You can have several jobs within a workflow.
- Steps — They are individual tasks executed inside the jobs. An example could be adding labels to your pull request or verifying certain files are included in your pull request. Each step is either a shell script that will be executed or an action that will be run.
- Actions — Or as I like to call them, pre-built bots. An action is just a custom application for the GitHub Actions platform that performs a complex but frequently repeated task. You can find them in GitHub’s marketplace.
- Runners — A runner is a server that runs your workflows. Each of these runners can run a single job at a time.
- Data Containers — You might need to store data when running your workflow, you have cache, artifacts, or variables for that.
Enough words, show me some pictures!
I hear you. That was a lot of information to digest. Take a look at the following schema, where I’ve attempted to show what our script would look like. No judgement here. It’s the best I could come up with the old iPad I borrowed from my sister.
As you can see, our bot is waiting for some event and as soon as someone creates a pull request, the bot will start checking for any workflows meeting the corresponding criteria. After looking through the list of workflows, our bot will find one that should be triggered every time a new pull request is created. The flow will, then, be placed in a queue and as soon as a runner is free, it will start running.
Are you still around? Still curious about how we translate this into actual working scripts? Take a look at the picture above, it shows the structure of the workflow we were talking about earlier. It starts by stating the type of event triggering the workflow — they can also be triggered manually — and it follows by including the jobs to be run, and each of the steps you need to follow to complete them.
How do the scripts actually look? — A simple example of a workflow
Here you can find an example of what a simple workflow would look like:
- name: Checkout
- name: Show Text
uses: echo Hello World!
The script shows a workflow called
basic-example triggered in any new event related to a pull request. It contains a job called
first-job running on a container with Ubuntu, and it’s composed of two steps.
The first step is just an action that checks out your repository under
$GITHUB_WORKSPACE and enables your scripts to run authenticated git commands. The second step is even simpler. It prints a ‘Hello World’ message in the terminal. As you can see, creating a workflow is not as complicated as it may seem!
I hope this article helped you understand a bit better what GitHub actions are about. You can now brag about your DevOps knowledge during the coffee breaks!
If you want to learn more about this topic, you can find more information on GitHub’s official site.