Part 02 - Just Enough Gitlab

5 min readJan 29, 2023

This article aims to provide a high-level overview of GitLab, sufficient to move on to the next set of chapters. However, it does not cover the fundamental concepts of GIT and assumes readers already have a basic understanding of commit, pull, and push. It is focused only on providing the necessary concepts to complete the steps in this series.

Let us get right to it.

1. Git ≠ Gitlab

Git and GitLab are both tools used for version control and source code management, but they serve different purposes.
In simple terms, Git is a tool that helps developers keep track of changes made to their code.
GitLab, on the other hand, is a web-based platform that provides additional features on top of Git. It provides a web interface for managing and collaborating on Git repositories, as well as additional functionality such as issue tracking, project management, and continuous integration/deployment. It can be installed on a server or used as a cloud-based service.

2. Groups, Subgroups, and Projects in Gitlab

In GitLab, groups are a way to organize projects and users. A group can contain multiple projects and multiple sub-groups, and it can have its own set of permissions and access controls.
Sub-groups are similar to groups, but they are nested within a parent group. They can be used to further organize projects within a larger group, and they can also have their own set of permissions and access controls.
Projects are the core of GitLab, they are where the codebase is stored and where developers collaborate on code. Each project can have its own set of files, issues, merge requests, and more. They can be assigned to a group or a sub-group, and they can have their own set of permissions and access controls.

In summary, groups are used to organize projects and users, sub-groups are used to further organize projects within a larger group, and projects are where developers collaborate on code and store the codebase.

where the boxes highlighted in blue are the “root” group, boxes in orange are the “subgroups” and green is the “project”

3. Gitlab CICD

GitLab Continuous Integration/Continuous Deployment (CI/CD) is a feature that allows developers to automate the process of building, testing, and deploying their code.

Just by the virtue of adding a file (.gitlab-ci.yml) will enable your repository to have the CICD capability.
Once this file is present, GitLab will automatically detect it and run the pipeline defined in the file when certain events occur, such as a code push or a merge request. The pipeline is defined in the .gitlab-ci.yml file as a set of jobs that are executed in a specific order.

Each job defines a set of commands that should be run and the environment in which they should be run.

Let us take a look at the .gitlab-ci.yml file in the just-enough-gitlab repository.

Each stage is a “phase” in the pipeline, and each job is an individual “task” that needs to be executed to complete the stage. Once “all” the jobs in a stage completes successfully, the pipeline moves to the next stage. If a job fails, the pipeline stops, and an error is reported.

Each stage executes sequentially.
Each stage can contain one or more jobs.
Each job in a stage will execute in parallel (by default)
Each job can only be present in a single stage.

In the above script, there are 3 stages namely “build”, “test” and “deploy”. Each stage has at least one job, the test stage has two jobs (test_job_1 and test_job_2). Jobs in the build stage are executed first, followed by test and then deploy.

4. Variables in CICD

Using variables in CICD, you can pass information to each pipeline at run time rather than hardcoding it in your code. The values passed are available as environment variables and can be used inside each job.
See Gitlab CICD for more information.

5. Gitlab Runners

GitLab Runners are a component of the GitLab Continuous Integration/Continuous Deployment (CI/CD) pipeline that runs jobs and send the results back to GitLab. They are responsible for executing the tasks defined in the .gitlab-ci.yml, such as building, testing, and deploying code. Runners can be installed on a variety of platforms, including Linux, Windows, and macOS, and can be run on-premises, in a container, or on a virtual machine.
If you are using gitlab.com, they provide you with shared runners (400 minutes per month), i.e you do not need to do anything, simply drop in the .gitlab-ci.yml file, and everything is taken care of for you.
If you are using a hosted version of Gitlab, you may need to verify if shared runners are enabled. Your organization’s Gitlab admins are the best people who can help you.
Alternatively, you can run the Gitlab runner inside your local machine or an EC2. See this link for options

In short, you need a runner to run your pipelines.

Conclusion

This article serves as an introduction to GitLab, providing a basic overview of its core features. However, it is important to note that GitLab offers much more than what is discussed in this article. It is not a comprehensive tutorial on the platform but rather aims to familiarize readers with the key concepts and help them understand how GitLab CI/CD will be used in future articles discussing different stages of the Terraform module lifecycle.