What is gitlab runner

Question

I think I'm fundamentally missing something. I'm new to CI/CD and trying to set up my first pipeline ever with gitlab.

The project is a pre-existing PHP project.

I don't want to clean it up just yet, at the moment I've pushed the whole thing into a docker container and it's running fine talking to google cloud's mysql databases etc as it should locally and also on a remote google cloud testing VM. The dream is to be able to push to the development branch, and then merge the dev banch into the test branch which then TRIGGERS automated tests (easy part), and also causes the remote test VM (hosted on google cloud), to PULL the newest changes, rebuild the image from the latest docker file (or pull the latest image from gitlab image register)... and then rebuild the container with the newest image.

I'm playing around with gitlab's runner but I'm not understanding what it's actually for, despite looking through almost all the online content for it. Do I just install it in the google cloud VM, and then when I push to gitlab from my development machine.. the repo will 'signal' the runner (which is running on the VM, to execute a bunch of scripts (which might include git pull on the newest changes?).

Because I already pre-package my app into a container locally (and push the image to the image registry) do I need to use docker as my executor on the runner? or can i just use shell and shell the commands in?

What am I missing?

TLDR and extra:

Questions:

1. What is runner actually for, where is it meant to be installed?
   Does it care which directory it is run in?
   If it doesn't care which directory it's run, where does it execute it's script commands? At root?

2. If I am locally building my own images and uploading them to gitlab's registry,

Do I need to set my executor to docker? Shouldn't I just set it to shell, pull the image, and build it? (Assuming the runner is runing on the remote VM).

Propjet

Answer 1

What is runner actually for?

You have your project along with a .gitlab-ci.yml file. .gitlab-ci.yml defines what stages your CI/CD pipeline has and what to do in each stage. This typically consists of a build,test,deploy stages. Within each stage you can define multiple job. For example in build stage you may have 3 jobs to build on debian, centos and windows (in GitLab glossary build:debian, build:centos, build:windows). A GitLab runner clones the project read the gitlab-ci.yaml file and do what he is instructed to do. So basically GitLab runner is a Golang process that executes some instructed tasks.

where is it meant to be installed?

You can install a runner in your desired environment listed here. https://docs.gitlab.com/runner/install/ or you can use a shared runner that is already installed on GitLab's infrastructure.

Does it care which directory it is run in?

Yes. Every task executed by runner is relativly to CI_PROJECT_DIR defined in https://gitlab.com/help/ci/variables/README. But you can alter this behaviour.

where does it execute it's script commands? At root?

Do I need to set my executor to docker? Shouldn't I just set it to shell, pull the image, and build it?

A runner can have mutiple executors such as docker, shell, virtualbox etc but docker being the most common one. If you use docker as the executor you can pull any image from docker hub or your configured registry and you can do loads of stff with docker images. In a docker environment normally you run them as the root user. https://docs.gitlab.com/runner/executors/README.html

Pastelist

I think the main point here is: When someone push a commit or merge a commit to master branch, how can runner know it to runt the pipeline? How does gitlab trigger runner? Or Does runner call api to gitlab every hours to check? – Chez

Every push, merge and pull request emit events. Gitlab listens for it and starts the runner. This is nearly all CI/CD tools do like Github Action, Jenkins and other. – Goddaughter

Answer 2

GitLab runner is a build instance which is used to run the jobs over multiple machines and send the results to GitLab and which can be placed on separate users, servers, and local machine. You can register the runner as shared or specific after installing it.

Shared Runners : These runners are useful for jobs multiple projects which have similar requirements. Instead of using multiple runners for many projects, you can use a single or a small number of Runners to handle multiple projects which will be easy to maintain and update.

Specific Runners : These runners are useful to deploy a certain project, if jobs have certain requirements or specific demand for the projects. Specific runners use FIFO (First In First Out) process for organizing the data with first-come first-served basis.

Protected Runners : The runners can be protected to save the important information.

Gynoecium