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 branch 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 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 running on the remote VM).

Answer 1

Let me address your first query, 'What is runner actually for?'

The project file is stored along with a .gitlab-ci.yml file. Note that, .gitlab-ci.yml defines the stages that the CI/CD pipeline has, it also defines what to do in each stage. It consists of build, test, and deploy stages. Within each stage multiple jobs can be defined.

e.g.:  In the build stage, we 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.

In other words, GitLab runner is a Golang process that executes some instructed tasks.

Now, let us see where this is meant to be installed.

We can install a GitLab runner in the desired environment listed here, https://docs.gitlab.com/runner/install/ or we also can use a shared GitLab runner that is already installed on GitLab's infrastructure.

Let us discuss if the directory it is run in actually matters?

Yes it does matter. Every task executed by the runner is relative to CI_PROJECT_DIR defined in https://gitlab.com/help/ci/variables/README. 

Now let us see where it executes it's script commands. At root? Do we need to set our executor to docker? Should we just set it to shell, pull the image, and build it?

A runner can have multiple executors such as docker, shell, virtualbox etc, docker is the most common one among all. 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 stuff with docker images. In a docker environment normally you run them as the root user. Refer to this official doc for more https://docs.gitlab.com/runner/executors/README.html