How to Build a CI/CD Pipeline using GitHub Actions
What is a CI/CD Pipeline?
First of all, let’s look at what is a CI/CD pipeline. CI/CD stands for continuous integration and continuous development. And this is an agile development workflow focused on frequent software delivery processes. CI/CD starts with continuous integration. This is a development practice that enables developers to create a consistent and automated way to build (the stage where the code is being compiled), Test (unit testing, validation testing, format testing) as soon as they integrate their code to a shared repository (e.g. — GitHub, GitLab). And this means, developers do not have to put their time and energy into building, testing, or deploying their code and the build server will do the heavy job for them. So, this helps developer teams to find bugs early, deliver faster code and deploy often.
The next step is continuous delivery. This stage ensures that the software can be released whenever is needed. So, this may involve manual interactions to approve a development. And finally, in the continuous deployment, every code change is deployed all the way to the production or to the end-users after passing through some integration tests to ensure code integrity.
What is GitHub Actions?
GitHub actions was introduced in 2018. GH offers workflow automation and CI/CD functionalities accessible directly through the repository itself. And it's free for all accounts with a maximum of 2000 minutes of workflow computation time per month.
Let’s Create a New Pipeline
In order to create a new workflow in your repository, you must create the actions file inside a .github/workflows. This is important!
.github/workflows/first-ci.yml
Now let’s create a new workflow file inside the folder and this should be a .yml / .yaml file
And your .yml file will look like this
As you can see, it has a very easy-to-learn syntax and is very easy to get used to it.
Now let’s go through the workflow commands one by one 👍
name:
name of the workflow, and it can be anything. If you omit the name, GitHub will name it to the workflow file path.
on:
specifies the triggers for your workflow and this is required. And it can be any event that can happen on GitHub or even in the entire GitHub ecosystem. So, this means, you can trigger events on apps that are installed on your repo (e.g.- Jenkins, Artifactory, GitHub events).
In this example, the workflow will trigger on push or pull request on the main branch. So, if you want to want to trigger the workflow in different branches as well, you can do it by adding the branch name in the array.
env:
Setting up environment variables. GitHub has a built-in secret store to make it easy and deploy to any package register or to any cloud. To create a secret, you need to go to repo setting and to secret tab and create a token.
jobs:
Here we are specifying the jobs that should be in the workflow run. And this can contain one or more jobs. And by default, these jobs are run in parallel, but if you need to run a specific job after another one or more jobs, you need to add a needs syntax to specify the jobs that must be complete before running this job.
As shown in the above picture, job2 will run only after job1 is completed and job3 runs only after job1 and job2 both completed.
strategy:
A build matrix strategy is a set of different configurations of the virtual environment. The job’s set of steps will be executed on each of these configurations. And in this case, jobs will be built across 3 different operating systems as well as 3 node versions. So, there will be 9 simultaneous jobs built at the same time.
matrix:
A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one version of a programming framework, operating system, runtime, or tool. A matrix uses the same job’s configuration and creates similar jobs for each matrix you configure.
runs-on:
The type of virtual machine that the job should run on. In this example, the virtual machine types are taken from the matrix os which is macOS, windows, and ubuntu.
steps:
Steps are a sequence of individual tasks running inside a job. And steps can run commands, setup tasks, actions in a repo.
uses:
Specify an action to run as part of a step in your job. You can define this action inside the same repository as the workflow or even reference an action that is in another repository, but you don’t need to install those actions or deal with anything, all you have to do is to reference it!
{owner}/{repo}@{branch/ref/SHA} for actions in a public repository{owner}/{repo}/{path}@{branch/ref/SHA} for actions in a subdirectory of a public repository./path/to/dir for actions in a subdirectory of the same repositorydocker://{image}:{tag} for actions on Docker Hubdocker://{host}/{image}:{tag} for actions in a public registry
with:
Map of input parameters defined by the action
run:
Instead of running an action on a repository, with a run command, you can run a command-line program using the operating system’s shell.
Now you can commit your code and push it. As soon as you push your code the pipeline will start its build.
And even you can see a visual representation of the build from the repository.
Resources
Open source projects that are using GitHub actions:
More Resources
https://github.github.io/actions-cheat-sheet/actions-cheat-sheet.pdf
