Skip to content

GitLab CI

Full sized image

You can build a complete CI/CD pipeline solution with one tool, it’s fast, and it’s open source. With GitLab CI/CD in the same place, you can create tickets, merge requests, write code and setup CI/CD tools without another application. It’s essentially a one-stop shop.

Runnes/Workers

GitLab CI/CD runs builds on GitLab Runners. Runners are isolated virtual machines that run predefined steps through the GitLab CI API. This tool, alone, allows for projects to run through the pipeline builds faster, compared to running on a single instance. You can learn more details about GitLab Runners in this link.

A runner can have mutiple executors such as docker, shell, virtualbox etc but docker being the most common one.

A GitLab runner clones the project, reads the gitlab-ci.yml file and executes the commands instructed in the gitlab-ci.yaml. So basically GitLab runner is a Golang process that executes some instructed tasks.

Configuration

To use GitLab CI/CD, all you need is an application codebase hosted in a Git repository, and for your build, test, and deployment scripts to be specified in a file called .gitlab-ci.yml, placed at the repository’s root. The scripts set in this file are executed by the GitLab Runner.

In this file, you can define the scripts you want to run, define include and cache dependencies, choose commands you want to run in sequence and those you want to run in parallel, define where you want to deploy your app, and specify whether you will want to run the scripts automatically or trigger any of them manually. Once you’re familiar with GitLab CI/CD you can add more advanced steps into the configuration file.

image: node:10.5.0
stages:
  - build
  - test
  - deploy
before_script:
  - npm install
build-min-code:
  stage: build
  script:
    - npm install
    - npm run minifier
run-unit-test:
  stage: test
  script:
    - npm run test
deploy-staging:
  stage: deploy
  script:
    - npm run deploy-stage
  only:
    - develop
deploy-production:
  stage: deploy
  script:
    - npm run deploy-prod
  only:
    - master

After creating the .gitlab-ci.yml file, it should be added to the Git repository and sent to GitLab.

GitLab CI/CD uses Runners to execute pipelines. We can define which operating system and predefined libraries we would want our Runner to be based off by using the image directive. In our instance, we will be using the latest version of Node.js for our Runner. The stages directive allows us to predefine a stage for the entire configuration. Jobs will be executed based off of the order listed in the stages directive. The before_script directive is used to run a command before all jobs.

There is a beginner tutorial available from: CI/CD essentials from scratch with Gitlab that explains the CI pipeline stages in great detail.

Gitlab CI + Docker

Different projects may require different dependencies such as Node.js, Ant, Maven. In the past when using a tool such as Jenkins, I’d have to make sure that all of these are installed on the server. By using Docker, the developer can reference dependencies available on Docker Hub without asking the server admin to setup such dependencies on the server each time.

GitLab Container Registry

GitLab Container Registry is a secure and private registry for Docker images. Built on open source software, GitLab Container Registry isn't just a standalone registry; it's completely integrated with GitLab.

Docker registry is a server-side application that allows you to host your own docker repository.

Docker Registry works the same as GIT Repository. You can commit your current container as an image and push it into the Docker Registry. You can also pull images back from the Docker Registry.

More details on: GitLab Container Registry guide

Further reading: