GitLab CI/CD: 3 Quick Tutorials

Article Content

What Is GitLab CI/CD?

GitLab CI/CD is a part of GitLab used for implementing various “continuous” methods, such as Continuous Integration (CI), Continuous Delivery (CD), and Continuous Deployment. GitLab CI/CD allows you to build, test, and publish software without needing a third-party integration or application.

You can use GitLab CI/CD to find errors and bugs early in the software development lifecycle (SDLC). It helps ensure the compliance of all code you deploy to production with the standards established for your application.

Tutorial #1: GitLab CI/CD Pipeline: Getting Started Tutorial

The following steps will help you get started with GitLab CI/CD. Before you start creating a CI/CD pipeline, you must have a project in GitLab (most actions in GitLab are done in projects). You save code and files in your project, with most features failing within the scope of a project.

Step 1. Create a GitLab project

To create a new project:

  1. Go to the top bar and click on Main menu. Go to Projects and select View all projects.
  2. Click on New project on the page’s right.
  3. Select one of the following options on the Create new project page:
  • Blank project
  • Built-in template
  • Custom template
  • Import a project from another repository
  • HIPAA audit template.
  • Connect to an external repository

Step 2: Ensure you Have Available Runners

To enable actions on GitLab CI/CD, you must make sure there are available runners to run the GitLab CI/CD jobs. A GitLab runner is an agent that runs CI/CD jobs.

If you use GitLab.com, you can skip to the next step because GitLab SaaS will provide the runners.

  1. View the available runners by going to CI/CD under Settings and expanding the Runners option. If you have one or more active runners (i.e., with green circles next to them), there will be a runner to process the CI/CD jobs.
  2. You may have an available runner, including a shared runner available to all projects in the GitLab instance. If this is the case, skip the next step.
  3. If there are no runners, you can install a GitLab Runner and register the runner for your group, instance, or project.

Step 3: Create a Job Definition File

Create a new .gitlab-ci.yml file at the repository’s root. This file will hold the definitions for your jobs. Define the following in the configuration file:

  • The jobs the runner must execute and their order.
  • The decisions the runner must make when encountering specific conditions.
    For example, you could run a test suite when committing to a branch other than the default branch (committing to the default branch should involve running the same test suite and publishing the application).

To create the .gitlab-ci.yml file:

  1. Go to Project information on the sidebar to the left and select Details.
  2. Select the desired branch above the file list, click on the plus icon, and select New file.

Image Source: GitLab

3. Enter .gitlab-ci.yml for the Filename and paste the relevant code in the large window.

For example:

build-job:
  stage: build
  script:
    - echo "Welcome, $GITLAB_USER_LOGIN!"

test-job1:
  stage: test
  script:
    - echo "This job tests something"

test-job2:
  stage: test
  script:
    - echo "This job tests something, but takes longer than test-job1"
    - echo "After the echo command completes, it runs the sleep command for 30 seconds"
    - echo "This simulates the test running 30 seconds longer than test-job1"
    - sleep 30

deploy-prod:
  stage: deploy
  script:
    - echo "This job deploys a commit from $CI_COMMIT_BRANCH"
  environment: production

$CI_COMMIT_BRANCH and $GITLAB_USER_LOGIN are defined variables that GitLab will populate when it runs the job.

4. Finally, click Commit changes.

The pipeline will start when a developer pushes a commit.

Step 4: View Status of Jobs and Pipelines

The pipeline should start after you commit the changes.

To view the pipeline:

  1. Go to CI/CD and select Pipelines.

It should display your pipeline, including three stages.

three_stages_v13_6

Image Source: GitLab

2. Select your pipeline’s ID to view its visual representation.

GitLab CI/CD pipeline view

Image Source: GitLab

3. To view a job’s details, select the desired job’s name – e.g., deploy-prod.

GitLab CI/CD job details

Image Source: GitLab

Tutorial #2: Using GitLab CI/CD with Kubernetes Clusters

GitLab CI/CD workflows allow you to update and deploy to a Kubernetes cluster safely. First, you have to install an agent in the cluster. You will now have the Kubernetes context needed to run Kubernetes API commands in the GitLab CI/CD pipeline.

To register an agent:

  1. Go to the Main menu and select Projects to find the project. The agent config file should be here.
  2. Click Infrastructure on the left sidebar and select Kubernetes clusters.
  3. Click Connect a cluster and select an agent config file (or create a new one).
  4. Click Register an agent. GitLab generates access tokens for agents, which you need to install in a Kubernetes cluster or update an agent.
  5. Copy the command from the Recommended installation method field.

To install an agent using Helm:

  1. Open your terminal to connect to the cluster.
  2. You should have copied a command when registering the agent with Gitlab – run this command.

A CI/CD workflow requires GitLab-registered runners, although they don’t have to be in the same cluster as the agent. To update a cluster with GitLab CI/CD:

  1. Ensure your Kubernetes cluster is working, and your GitLab project contains the manifests.
  2. Register and install the agent in your project.
  3. Update the .gitlab-ci.yml file and select your agent’s Kubernetes context.
  4. Run the Kubernetes API commands.
  5. Run the pipeline to update or deploy to the cluster.

Tutorial #3: Using GitLab CI/CD with a Docker Registry

Once you integrate the Docker container registry into GitLab, you can use a dedicated space to store the Docker images for each GitLab project.

To view the container registry for your group or project:

  1. Go to the group or project.
  2. Navigate to Packages and registries and select Container Registry.
  3. Search, filter, sort, or delete your containers on the container registry page.

Only group or project members should have access to the project’s container registry (if private). Public projects have a publicly accessible registry.

To see a list of the tags associated with a container image:

  1. Go to your group or project, Packages and registries, and select Container Registry.
  2. Select your desired container image to view the Tag Details page, which includes details such as the tag’s publishing date, storage consumption, etc.

To download an image from a container registry:

  1. Copy the container image’s link.
  2. Go to Packages and registries for your group or project and select Container Registry to find your desired image.
  3. Copy the image name and use the image link to use the Docker run command.

To authenticate with a container registry:
You can use a personal, project, or group access token (or deploy token). Run the Docker command:

docker login registry.example.com -u <username> -p <token>

Related content: Read our guide to GitLab CI example 

Combine GitLab with Codefresh to Support GitOps and Kubernetes Deployments

GitLab is a very powerful platform but it is focused mostly on CI and does not support GitOps and native Kubernetes deployments. Codefresh is created specifically for GitOps and Cloud native applications and includes native support for using GitLab as a Git provider.

This means that you can get the best of both worlds by keeping all your CI workflows in GitLab, while using Codefresh for advanced features such as:

  • Application dashboards
  • Git source managements
  • Configuration drift management
  • Kubernetes environment dashboards
  • Topology views

In case you are new to Codefresh – we have made it our mission since 2014 to help teams accelerate their pace of innovation. Codefresh recently released a completely rebuilt GitOps CI/CD toolset. Powered by Argo, Codefresh now combines the best of open source with an enterprise-grade runtime allowing you to fully tap the power of Argo Workflows, Events, CD, and Rollouts. It provides teams with a unified GitOps experience to build, test, deploy, and scale their applications.

The World’s Most Modern CI/CD Platform

A next generation CI/CD platform designed for cloud-native applications, offering dynamic builds, progressive delivery, and much more.

Check It Out
Related GitLab CI articles