Quick Introduction to GitLab CICD Pipelines
git init or creating a Git repository from UI is usually the first step to start a development process. We all want to keep track of the changes in our code and test/deploy them immediately after each commit. The ideal way to do this is to create a webhook to an automation server like Jenkins and define the steps in the automation server. The downside of this approach is that you also need to install, configure and maintain the automation server.
The idea behind the GitLab CICD pipelines is to provide you with a ready-to-use environment and abstract the need to set up and maintain the automation server.
GitLab CICD pipeline is a structured pipeline written in the YAML language. If you create a .gitlab-ci.yml file in your project's root, GitLab will automatically understand that you want to implement a pipeline against your project and it will calculate the pipeline steps before it starts running.
Pipeline steps are calculated before it starts running. Keeping that in mind can help you to troubleshoot some of the issues you might face in your pipeline, especially if you are surprised that why certain step of the pipeline has run or not.
Let's go through a simple pipeline file below:
If you commit this file as .gitlab-ci.yml in your project's root directory, GitLab will pick it up and will create a pipeline for you.
The file itself is self-explanatory. Here we tell our pipeline to run two stages, stage1 and stage2. Under stage1, we create a job called First Job and under the script section, we define what it needs to do. Similarly we create the Second Job to run under stage2. Both jobs are running the tasks inside a openjdk:19-slim image that GitLab runner pulls.
You can check the status of your pipeline from CI/CD -> Pipelines on the left pane of GitLab UI.
Your pipeline uses agents/processes called GitLab Runners to run the steps defined in the pipeline file. You can have your own runners or you can use the shared runners based on your requirement. Let's take a look at the output of the first task and investigate what it does:
The first 8 lines tell us the details about the GitLab runner and the image we used. Then till line 19, it clones the repository to a workspace under the initialized image instance. After line 19, it executes the script steps we provided in the job.
If we take a look at the 2nd job, then we will realize that it didn't print out the environment variable we set in the first job:
As you can see above, it is again initializing the environment by pulling in the openjdk:19-slim image and then cloning the repository to a new workspace and running the tasks in the script field as we defined in the pipeline. The most important thing to note here is that the TEST_VAR variable is not set in the 2nd job because jobs do not inherit the variables assigned in the previous jobs/stages by default. Each job initializes its own workspace which means the files and variables created in the previous steps will not be inherited automatically. There are ways to inherit them and we will mention them in the next chapters.
Let's also have a quick look at configuration options in GitLab UI for pipelines under Settings -> CI/CD.
Last updated
