How should we use GitLab CI/CD pipeline and finally deploy our code to Heroku?- PART-2

6 min readMar 22, 2020

In this article, I will mostly cover the description part and most of the points where I fell into trouble.

Below is the picture for the agenda: —

As we are already done with the basic setup of the application in the GitLab repo of the part-1, so here goes the description of what exactly the GitLab runner, docker Executor, and GitLab registry are.

Here is how they are connected to each other:-

GitLab Runner that uses Docker image

GitLab Runner Docker images (based on Ubuntu or Alpine Linux) are designed as wrappers around the standard gitlab-runner command, like if GitLab Runner was installed directly on the host.

The general rule is that every GitLab Runner command that normally would be executed as:

gitlab-runner <Runner command and options...>

can be executed with:

docker run <chosen docker options...> gitlab/gitlab-runner <Runner command and options...>

For example, getting the top-level help information for GitLab Runner command could be executed as:

docker run --rm -t -i gitlab/gitlab-runner --helpNAME:
   gitlab-runner - a GitLab RunnerUSAGE:
   gitlab-runner <global options> command <command options> <arguments...>VERSION:
   10.7.0 (7c273476)(...)

In short, the gitlab-runner part of the command is replaced with docker run [docker options] gitlab/gitlab-runner, while the rest of Runner’s command stays as it is described in the register documentation. The only difference is that the gitlab-runner a command is executed inside a Docker container.

You can install your gitlab runner either via docker image or shell executor. Below is the link for the same.

https://docs.gitlab.com/runner/install/docker.html

The Docker executor

GitLab Runner can use Docker to run jobs on user provided images. This is possible with the use of Docker executor.

The Docker executor when used with GitLab CI, connects to Docker Engine and runs each build in a separate and isolated container using the predefined image that is set up in .gitlab-ci.yml and in accordance in config.toml.

That way you can have a simple and reproducible build environment that can also run on your workstation. The added benefit is that you can test all the commands that we will explore later from your shell, rather than having to test them on a dedicated CI server.

GitLab Container Registry

A registry is a storage and content delivery system, holding named Docker images, available in different tagged versions.

Example: the image distribution/registry, with tags 2.0 and 2.1.

GitLab container registry allows to make your code publicly accessible either by docker image or any other source of truth that contains your code.

Note: If you cannot find the Packages > Container Registry entry under your project’s sidebar, it is not enabled in your GitLab instance.

When we set up our CI environment: -

We set up a CI environment on GitLab, added a .gitlab-ci.yml in the root of our repository.

This file contains definitions of how our project should be built and our Gitlab Runner (which you set up in part-1 of this post) will search for this file in your repository and execute it within the environment of the Runner.

This is how I set up my .gitlab-ci.yml. You may wish to tweak it depending on your project. But of course, before you push up your project to Gitlab, it is good practice to run it by the YAML validator first to make sure it’s valid if not, it will result in errors. I will explain the various components in my YAML file.

image: node:6.10.3stages:- ver- init- tests- deployver:stage: verscript:- node --version- whoamiinit:stage: initscript:- npm cache clean- rm -rf node-modules- npm installrun_tests:stage: testsscript:- npm testdeploy_staging:stage: deployscript:- git remote add heroku https://heroku:$HEROKU_API_KEY@git.heroku.com/text-giving-staging.git- git push heroku master- echo "Deployed to staging server"environment:name: stagingurl: https://text-giving-staging.herokuapp.com/only:- masterdeploy_production:stage: deployscript:- git remote add heroku https://heroku:$HEROKU_API_KEY@git.heroku.com/text-giving.git- git push heroku master- echo "Deployed to production server"environment:name: productionurl: https://text-giving.herokuapp.com/when: manualonly:- master

image: allows you to specify a certain version of NodeJS you want to use during build time

stages: define build stages. In this case, we have ver, init, tests, and deploy, but you can change the names of the stages to what you deem fit for your project.

stage ver: node —-version allows us to check the version of NodeJS we are using and whoami reveals whether the user has permissions, which makes it easier to debug when things go wrong.

stage init: we clean the npm cache, remove the node modules, install it and then we run the tests which we have written previously.

stage tests: we want to run the tests to make sure all the tests pass.

stage deploy: we will add a remote to the repository using the Heroku API key. We can retrieve the Heroku API key from the Accounts setting page in Heroku.

Register the Gitlab Runner

As we have GitLab runner description above along with its basic setup. Next, register the Gitlab Runner by following instructions here: https://docs.gitlab.com/runner/register/index.html. Again, it should be fairly straightforward to follow. For the runner executor, I chose to run it on the shell which is the easiest to configure (you may choose other options if you prefer). After registering, install and start the service with the following commands:

gitlab-runner install
gitlab-runner start

You may check if the runner is running with the following command:

gitlab-runner status
gitlab-runner: Service is running!

So this is all that I did to set up the CICD pipeline in GitLab and finally hosted my website on Heroku.

Last but not least here are some open links and troubles that I came across during my entire journey to set it up.

What exactly the GitLab runner and Docker executors are. So for that (https://www.youtube.com/watch?v=IHxcsEX3tjo&list=PLaFCDlD-mVOlnL0f9rl3jyOHNdHU--vlJ&index=6) this tutorial has provided me a lot of help.
There could be a chance that you want to set up more than one project in your GitLab account for the hosting purpose. So, in that case, you need to install gitlab-ci-multi-runner in your local.
You might be having the requirement at some point in time that you instantly need to make changes in both of your repositories and as per your .Gitlab-ci.yml file both CICD pipeline will start instantly but after some time one will fail to say that, another pipeline is already in progress.
There could be a situation when you just wanna deploy a static HTML CSS website and Heroku will not allow you to do that saying that you are not having any particular environment set up for your project. So, in that case, you can follow this link it will help you out in setting up the environment with a small hack.
Some of you can also get some errors related to your .gitlab-ci.yml file. As you can see there are some beforeScripts written over there. They may break as per GitLab OS. Mac is the OS they are using so brew will work but in some cases, you need to install the package manager first then only that error will be gone.
I have both types of applications set up in my GitLab repository for your reference.
Knowledge of docker is mandatory. It will help you out in many cases and you will be able to do your many tasks very easily with its simple commands.