When you develop your code continuously, it is important to make sure that your code is always compilable and has no problem, especially coding with others. If not, anyone can code the way he or she thinks right but can actually ruin the whole code which was originally had no problem.
This is why continuous integration(CI) is needed. Continuous Integration is a process of checking and testing the code before integrate it with existent code. For example, when you make a pull request in github, your code is checked and tested before merge and only after there is no problem while checking and testing your code, merge is allowed.
As CI is important for keeping code safe, there are many CI platforms like Jenkins, Travis and Github Action which you can use. These platforms each have pros and cons and there is no answer which one to use. You just have to make a choice.
In this article, I will show you how to use Github Action to set up CI in your project. So, let’s jump right in.
Github Action?
so, what is Github Action?
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline, according to documentation.
The fact that Github Action is a CI/CD platform provided by github is a huge advantage, which makes Github Action so attractive. To use Github Action, you don’t need to configure your server or integrate other third party service. When you use jenkins, you have to configure your own server. When you use travis, you have to integrate travis to github and pay for usage.
For Github Action, all you need is github account which you may already have and some files required by Github Action in your project. In summary, for those who already use github, all they have to do is just add some files in your project. Then, github will do all the others. Also, it’s free for Storage of 500MB and 2000 Minutes per month, which was enough for me.
Github Action provides Linux, Windows and macOs virtual machines to run your job, which means that you can run or test your code in any os of your choice without any configuration. Each job will run in a fresh, newly-provisioned virtual machine. For example, if you want to build your code in linux and test your code in macOs, it is no problem for you if you use Github Action. It’s awesome isn’t it? 😆
So, How do I start?
Github Actions uses YAML syntax to define the workflow. Each workflow is stored as a separate YAML file in your project, in a directory called .github/workflows. For short, you have to create .github/workflows directory in root of your project and write YAML file in the directory.
I’ll show you the final result of this article.
That’s it. Isn’t it easy? 😅
Just one file to set up your CI process. 😲
What’s in that file?
Let’s get deep dive in that file following each steps.
If you’re familiar with YAML syntax already, it will be easy. If you’re not, don’t worry. It’s not that hard.
name(Optional)
In your github repository, you will see Actions tap. In the tap, there is Workflows section and the name will appear there. You can think of Workflows as a YAML file in .github/workflows directory. Each file defines workflow.
on
specifies the trigger for this workflow. As I use pull_request event, every time pull request occurs, the workflow I defined in CI.yml will run.
jobs
This is where you define the jobs you want to run in this workflow. It’s pretty self-explanatory. As this is workflow for CI, I build and test the code.
Each job runs in different runner and runs parallel with each other.
If I add another job, which may be build and push docker image to docker hub or ECR, it will run in another runner which I can configure macOs, not necessarily ubuntu-latest and run parallel with Build_Test job.
On the other hand, steps in jobs are executed in order and are dependent on each other. Also, each step is executed on the same runner, so you can share data from one step to another. In my example, I test the code after I build the code.
First, you define name of your jobs, which is Build_Test in the example.
Then, you define in which runner you run the job. A runner is a server hosted by Github. that runs your workflows when you’re triggered. Each runner can run a single job at a time. Every time, each job is executed in a fresh, newly-provisioned virtual machine. In summary, whenever PR is created, I run Build_Test job in a fresh ubuntu-latest virtual machine.
Then, we write action or shell script under steps section.
First, I use checkout action which is already made from others and is used to checks out my repository onto the runner to build and test my code later. Beside checkout action, you can use any action that is listed on github action marketplace.
After I checkout my code, I setup node.js using setup-node action in a runner because the runner is fresh, nothing installed ubuntu virtual machine. I specify the node version and I cache yarn for shorter setting time later.
Then, I also cache the node_modules using cache github action. When dependencies remain same, then runner use the cached node_modules rather than install from beginning. However, when dependencies change, the hash of yarn.lock changes so, runner create new cache.
Then I install dependencies which is mainly done fast as I cache yarn and node_modules and build and test using scripts.
That’s it! Pretty easy right? 😅
Conclusion
So far, we looked into what is github action and how to use it setting up yml file. As you know if you follow up the steps, github action is slower than other tools because every jobs run in fresh, clean virtual environment, which is why caching is important. Despite the slow speed, Github Action is excellent choice for CI / CD. It is also useful for handling github events like creating issues or mention in issues… I recommend you use github action in your project. I hope this article helps you well. Thank you 😄
