Skip to content

3. Setting up CI/CD pipeline

Guide for setting up a Gitlab pipeline to automate the re-deployment of PrestaShop to cPouta whenever new commit are pushed to the repo. Furthermore, a gitlab runner will be installed to run our pipeline

Original Author: Petri Peltomaa
Last updated by Amna Akram
Last checked by Henri Kautto
Version 0.1
Lastmod: 21.10.2025
Status: Needs testing
Comments: In Progress

Notes#

This guide references the following repos:

  • Production pipeline is the repo that contains the pipeline to deploy PrestaShop service as a whole to the Rocky Linux VM. Files related to the deployment are in here.
  • PrestaShop image to pull docker image for PrestaShop from internal repos
  • MySQL image to pull the docker image for MySQL from internal repos

Introduction#

GitLab Runner is an application that works with GitLab CI/CD to run jobs in a pipeline.

In this guide we will install and register a custom Gitlab runner. (Even though runners are provided with Jamk's Gitlab server, they get shared by everyone using Gitlab at Jamk, which means queuing in line waiting for your job to run. To avoid this, we will install our own Gitlab runner on our server, and make sure our deployments are handled by that runner).

Once the runner is working, we will configure our pipeline. This involves creating variables related to our deployment in Gitlab, and creating a .gitlab-ci.yml file in the root of our project to describe exactly what steps should be run.

Lastly, we specify which runner should be used to run the pipeline using tags.

Prerequisites#

Installing, creating and registering the runner#

1. Install package on Server#

First, install a runner to the server (VM) to receive signals from gitlab pipeline jobs

SSH into the cPouta VM and download .rpm files for the runner package

# Download .rpm files
curl -LJO "https://s3.dualstack.us-east-1.amazonaws.com/gitlab-runner-downloads/latest/rpm/gitlab-runner_amd64.rpm"
curl -LJO "https://s3.dualstack.us-east-1.amazonaws.com/gitlab-runner-downloads/latest/rpm/gitlab-runner-helper-images.rpm"

install the package

sudo dnf install -y gitlab-runner-helper-images.rpm gitlab-runner_amd64.rpm

2. Create a runner in Gitlab#

Second, create a runner by following these steps

To create a runner for the pipeline jobs, go to the repo -> settings -> CI/CD -> runners

Screenshot: CI/CD link in sidebar Screenshot: Create project runner

Give the runner a tag and description etc.

Screenshot: runner details

Choose linux and then you get specific commands on how to register your runner.

Screenshot: choose runner platform

3. Register the runner#

On the server, run this command after the runner is installed to start the registering process.

sudo gitlab-runner register  --url https://gitlab.labranet.jamk.fi  --token glrt-your-token

Answer the questions as follows:

  • Gitlab instance URL: Should be already correct but if not use https://gitlab.labranet.jamk.fi
  • Name: presta
  • Executor: docker
  • Docker image: alpine:latest

You should get something like below

After that make sure that the docker sock is enabled in the config file (/etc/gitlab-runner/config.toml)

Gitlab variables#

Make necessary variables for the pipeline's jobs to use. This way we can keep password and other secrets safe.

To make variables go to the setting -> CI/CD -> variables.

It is also possible to mask and hide variables, this prevents accidental prints that would show sensitive data in logs.

Configuring pipeline#

See the final .gitlab-ci.yml file at ref-product-service-production-pipeline-v1

Runner usage in pipelines#

Now that the runner is created we can simply use the runner inside the gitlab-ci.yml file. To tell what runner you want to use, simply give the appropriate tag inside the gitlab-ci.yml file.

For example like this:

deploy:
  stage: deploy
  tags: [presta] # this defines the runner to be used for this job
  image: alpine:3.20
  ....

The gitlab-ci.yml is what "orders" the pipeline to do different jobs and what runner to pick for a job.

How to get access to another repository's container registry#

Pipeline can only use that container registry's image that it is ran from. So therefore we need to have the ability to pull from another repo's container registry if we wish to use other images not available in the repo where the pipeline is ran from. To achieve this we need to create a deploy token.

In gitlab go into Settings -> repository -> deploy tokens. (in the repo where you want to pull images from)

After that create the token and be sure to save the password since it cannot be recovered or seen after the fact. Give that token necessary permissions (read_registry) in this case because we want to read the container registry. Give a name and a username to the token.

After it is created you will get a password, save that!

After this is done, we can login to the container registry of that repo. Useful thing to do is to make Gitlab variables for the token's password and username. (these variables are made in the projects repo where the pipeline is ran from)

Now we should be able to use these variables to login to the other repo's container registry and pull images from there. See example code snippet below.

NOTE - Be sure to create deploy tokens to all repositories where you want images pulled from. So in this case we need to have permission to read from the prestashop and mysql repo's container registries

For example like this:

    # Login to Presta repo registry and pull the image
    - docker login gitlab.labranet.jamk.fi:4567 -u "$PRESTA_REGISTRY_USER" -p "$PRESTA_REGISTRY_PASSWORD"
    - docker pull gitlab.labranet.jamk.fi:4567/ref-product-line-v1-2025/ref-product-presta-shop-service-container-v1:latest

    # Login MySQL private registry with deploy-token and pull the image
    - docker login gitlab.labranet.jamk.fi:4567 -u "$MYSQL_REGISTRY_USER" -p "$MYSQL_REGISTRY_PASSWORD"
    - docker pull gitlab.labranet.jamk.fi:4567/ref-product-line-v1-2025/ref-product-service-mysql-database-container-v1:latest
  ....

Here we use two login steps because we want to use the container registry of the repo where pipeline is ran from and then the other repo's container registry.

References#