Automate, Accelerate, Accurate

Main menu

Post navigation

PowerShell and GitLab CI – Part 2

Setting up a Windows GitLab Runner

Part 1 of this series on PowerShell and GitLab CI saw us setup our GIT client configuration, register and configure GitLab for our sample project, and then perform an initial clone of the project just created.

Todays blog covers the setup of a Gitlab Runner.

What is a GitLab Runner?

Quite simply, a GitLab Runner is an application which processes builds. On a Windows system, a GitLab Runner operates as a dedicated service. Because it communicates with GitLab CI through an API, there is no requirement to have the Runner on the same server on which you have GitLab CI installed. Runners can be setup on various operating systems, and additionally process multiple languages.

GitLab CI can use one or more Runners. This makes it not only handy when we are working in a heterogenuous environment, but also where we wish designated severs for our development, testing, acceptance, and production arenas.

Runners can be assigned per project, which gives us further flexibility. I find this very helpful, working in an environment with multiple untrusted forests. All I need to do is register a Runner in the respective forest, and then assign it to a project for that.

Preparation

Before we download and install the Windows Runner software, we need to get an identifier from GitLab. This will be used to associate a runner with a project.

Log back into GitLab

Click {yourname} / helloworld

Click Runners on the left hand pane

Copy the registration token in section 3 of How to setup a new project specific runner into the clipboard.

Installing and Configuring the Runner

Now we’ll actually get the runner operational on our build server.

Move gitlab-ci-multi-runner-windowsd-amd64.exe to a suitable directory. Note that this will be the directory from which the service runs. As this is a demo, I am going to place it in the Temp folder of my C: drive.

Start PowerShell as an administrator

Use Set-Location to set the current directory to the location of the file mentioned above

Use the command below to launch the configuration utility

PowerShell

1

.\gitlab-ci-multi-runner-windows-amd64.exe register

You’ll now be prompted for input some information

coordinator URL : https://ci.gitlab.com

token : <paste the registration token you copied to the clipboard>

description : hellowworldrunner

tags : windows

executor : shell

Coordinator URL refers to the location that the runner looks to for communication with GitLabCI, Token the unique identifier that is used to identify your runner. Tags allow you to control when a job does or doesn’t build on a runner, and the executor refers to the type of script it will process.

If you are prompted for your current password, enter this as well.

Launch services

Find the service with the name of gitlab-runner

Note is the service is registered to run in the current context of your account.

Unless you have any specific need to keep the gitlab-runner service running in this context, carry out the following:

Stop the service

Change the Log On as: setting to the account you want it to run under. (In my case, I just set it to Local System Account.)

Start the service

That’s the Runner setup, and ready to be used, but first took a look at the location where the process runs from.

You should see a file there new called config.toml. This file contains the configuration settings that the Runner uses. It’s plain text, so you can open it in Notepad. It details the number of concurrent runners, the url of the gitlab cim, the token we used earlier for registration, name of the runnier, and other configuration data.

Now return to GitLab, and the Runners section we were just on, and press F5 to refresh the screen.

The helloworld runner should now be registered for this project!

In part 3 of this series, we’ll create our first GitLab CI build file, which will run a basic PowerShell script.