Why Chose GitLab Over Other CI tools?

If there are many tools available in the market, like CircleCI, Github Actions, Travis CI, etc., what makes GitLab CI so special? The easiest way for you to decide if GitLab CI is right for you is to take a look at following use-case:

GitLab knocks it out of the park when it comes to code collaboration and version control. Monitoring the entire code repository along with all branches becomes manageable. With other popular tools like Jenkins, you can only monitor some branches. If your development teams are spread across multiple locations globally, GitLab serves a good purpose. Regarding price, while Jenkins is free, you need to have a subscription to use all of Gitlab’s features.

In GitLab, every branch can contain the gitlab-ci.yml file, which makes it easy to modify the workflows. For example, if you want to run unit tests on branch A and perform functional testing on branch B, you can simply modify the YAML configuration for CI/CD, and the runner will take care of running the job for you. Here is a comprehensive list of Pros and Cons of Gitlab to help you make a better decision.

Intro

GitLab is an open-source collaboration platform that provides powerful features beyond hosting a code repository. You can track issues, host packages and registries, maintain Wikis, set up continuous integration (CI) and continuous deployment (CD) pipelines, and more.

In this tutorial, you will configure a pipeline with three stages: build, deploy, test. The pipeline will run for each commit pushed to the repository.

GitLab and CI/CD

As we all are aware, a fully-fledged CI/CD pipeline primarily includes the following stages:

• Build
• Test
• Deploy

Here is a pictorial representation of how GitLab covers CI and CD:

Let’s take a look at an example of an automation testing pipeline. Here, CI empowers test automation and CD automates the release process to various environments. The below image perfectly demonstrates the entire flow.

‍

Let’s create the basic 3-stage pipeline

Step 1: Create a project > Create a blank project

Visit gitlab.com and create your account if you don't have one already. Once done, click “New Project,” and on the following screen, click “Create Blank Project.” Name it My First Project, leave other settings to default for now, and click Create.
Alternatively, if you already have your codebase in GitLab, proceed to Step 2.

Step 2: Create a GitLab YAML

‍To create a pipeline in GitLab, we need to define it in a YAML file. This yaml file should reside in the root directory of your project and should be named gitlab-ci.yml. GitLab provides a set of predefined keywords that are used to define a pipeline. 

In order to design a basic pipeline, let’s understand the structure of a pipeline. If you are already familiar with the basic structure given below, you may want to jump below to the advanced pipeline outline for various environments.

The hierarchy in GitLab has Pipeline > Stages > Jobs as shown below. The Source or SRC  is often a git commit or a CRON job, which triggers the pipeline on a defined branch.

Now, let’s understand the commonly used keywords to design a pipeline:

1. stages: This is used to define stages in the pipeline.
2. variables: Here you can define the environment variables that can be accessed in all the jobs.
3. before_script: This is a list of commands to be executed before each job. For example: creating specific directories, logging, etc.
4. artifacts: If your job creates any artifacts, you can mention the path to find them here.
5. after_script: This is a list of commands to be executed after each job. For example: cleanup.
6. tags: This is a tag/label to identify the runner or a GitLab agent to assign your jobs to. If the tags are not specified, the jobs run on shared runners.
7. needs: If you want your jobs to be executed in a certain order or you want a particular job to be executed before the current job, then you can set this value to the specific job name.
8. only/except: These keywords are used to control when the job should be added to the pipeline. Use ‘only’ to define when a job should be added, whereas ‘except’ is used to define when a job should not be added. Alternatively, the ‘rules’ keyword is also used to add/exclude jobs based on conditions.

You can find more keywords here.

Let’s create a sample YAML file.

CODE: "https://gist.github.com/velotiotech/f770d62338b576002538fa30a967607f.js"

As you can see, if you have your scripts in a bash file, you can run them from here providing the correct path. 

Once your YAML is ready, commit the file. 

Step 3: Check Pipeline Status

‍Navigate to CICD > Pipelines from the left navigation bar. You can check the status of the pipeline on this page.

Here, you can check the commit ID, branch, the user who triggered the pipeline, stages, and their status.

If you click on the status, you will get a detailed view of pipeline execution.

‍

If you click on a job under any stage, you can check console logs in detail.

‍

If you have any artifacts created in your pipeline jobs, you can find them by clicking on the 3 dots for the pipeline instance.

‍

‍

Advanced Pipeline Outline

For an advanced pipeline that consists of various environments, you can refer to the below YAML. Simply remove the echo statements and replace them with your set of commands.

CODE:"https://gist.github.com/velotiotech/51c60a7a29d63ff5c55e19eccccd5908.js"

Conclusion

If you have worked with Jenkins, you know the pain points of working with groovy code. Thus, GitLab CI makes it easy to design, understand, and maintain the pipeline code. 

Here are some pros and cons of using GitLab CI that will help you decide if this is the right tool for you!