Picture this scenario, you are trying to set up a system where your tests are run every time a pull request is made to ensure changes pushed to the repo do not break the production server or some other CI/CD tasks and you need to do it as simply, efficiently, and effectively as possible.
Well I was faced with the same dilemma a few weeks ago and after doing a little research, I came across github actions and came to the conclusion that it was the easiest and most efficient tool I could use to achieve my goal.
So first of all, what are github actions?
Well, github actions is a platform that allows developers to automate activities such as building, testing, and deployment of their applications all within a github repository. Github docs classifies it as a continuous integration and continuous delivery (CI/CD) platform.
To start using and taking advantage of github actions, there are a few things that we would have to understand.
Workflows: this is the section of a github action that is run after an event is triggered. it is an automatic process
and is made up of a series of specified activities or jobs that run when an event is triggered.
Workflows are defined in a YAML file in the repo. To define a workflow, simply create a folder called .github at the base of the application, then create a folder called workflows within the .github folder. This is where the YAML files containing your workflows would be located. A workflow can house several jobs.Events: an event is an action or anything that can happen in a github repository. An event can be anything from creating
a pull request to pushing code to the repo, creating a new branch, or even creating or commenting on an open issue. Events are the components of github actions that are used to trigger or start the sequence of activities or jobs in a workflow. A list of all events available for use can be found in the official github documentation here.Jobs: a job can be said to be the part of a workflow that contains or houses a series of steps that get executed in the same runner when a workflow is run. Steps in a job are executed in order from top to bottom and each successive step is dependent on the previous step to run
Steps: a step in a workflow is simply an action or a shell script that is part of a job and is executed on the runner which runs the job. steps are run sequentially unlike jobs which are run concurrently unless otherwise stated.
Runners: a runner can simply be thought of as a virtual machine that uses a defined operating system to run the steps in a workflow's job. Each runner is responsible for running a job in the workflow i.e a runner is created for every job in the workflow. Github hosts runners for workflows on the cloud however, runners can be self-hosted in custom cloud environments.
Creating a workflow file
A simple workflow
In the figure above,
Line 1: name of the workflow
Line 3 - 5: refers to the event that triggers the workflow's jobs. This particular workflow is triggered once code is pushed to the master branch of the repo
Line 7: specifies the jobs in this particular workflow
Line 8: name of the particular job i.e print-hello-world
Line 9: specifies the operating system of the runner in which the job would be run on i.e the latest version of ubuntu
Line 11: specifies the steps in the jobs
Line 12 - 13: specifies the name of the step as well as the command to be run i.e echo "hello world"
Workflow result
In this section, we learnt the basics of github actions and learnt how to setup a simple github action. In the next section, we would learn how to setup automated tests using github actions.
Top comments (2)
GitHub Actions has become my favorite automation platform. It's easy to use and debug and the marketplace is loaded with useful stuff. They're generous with all the free time they give out too, but it's still easy to setup your own runners if you want.
I particularly like the fact that you can get actions for almost any activity you want to automate or atleast get actions that reduce the amount of code you'd have to write.