GitLab Runner for Windows Headless

Or how windows und kubernetes became “best friends” with the help of GitLab Runner

Today, Florian (Cloud Consultant at teuto.net), tells us in a tutorial about his experiences of bundling windows applications in docker containers.

The world around microsoft windows has also made acquaintance with docker and now also kubernetes. In order to be able to bundle windows applications in appropriate Docker containers, we need a windows host. It makes sense to integrate our windows applications with GitLab-CI. For this we need the GitLab Runner on our windows host and connect it with our GitLab.

Requirements

In this tutorial, we need a windows host with OpenSSH installed to issue our command-line or PowerShell commands to the host. We also use scoop (https://scoop.sh/) to install additional software like Git. We also need admin access for the GitLab instance we want to connect to the GitLab Runner. At the beginning we connect via SSH to our windows host and set up a directory for GitLab-Runner.

Verzeichnis vorbereiten

Microsoft Windows [Version 10.0.17763.379]
(c) 2018 Microsoft Corporation. All rights reserved.

administrator@WIN-BUILDER-3 C:UsersAdministrator>powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

PS C:UsersAdministrator>mkdir C:GitLab-Runner
PS C:UsersAdministrator>cd C:GitLab-Runner

Install Prerequisites

scoop is a package manager with which we can install a variety of nice tools. For example, we need Git.

scoop installieren

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')

git installieren

scoop install git

Install GitLab Runner

Typically, the gitlab-runner.exe can be downloaded from the PowerShell command Invoke-WebRequest. In our experience, however, this is very slow.

GitLab-Runner Download: Invoke-WebRequest

Invoke-WebRequest -UseBasicParsing https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe -OutFile gitlab-runner.exe

It is faster to download the file locally and then copy it via scp to the Windows host. First we download the GitLab-Runner to our local machine: https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-windows-amd64.exe

According to the following scheme we can copy the file via scp to our windows host:

$ scp ~/Downloads/gitlab-runner-windows-amd64.exe Administrator@<Windows-Host-IP>:C:/GitLab-Runner/gitlab-runner.exe

If the downloaded file is now available under C:GitLab-Runnergitlab-runner.exe we install the service.

PS C:GitLab-Runner> .gitlab-runner.exe install

Runtime platform                                    arch=amd64 os=windows pid=736 revision=de7731dd version=12.1.0

Under the URL https://<GitLab-URL>/admin/runners we get the token we need to connect the runner with GitLab.

PS C:GitLab-Runner> .gitlab-runner.exe register --non-interactive --url https://<GitLab-URL> --registration-token <TOKEN> --executo
r shell --locked=false
  
Runtime platform                                    arch=amd64 os=windows pid=3424 revision=de7731dd version=12.1.0 
Registering runner... succeeded                     runner=Pss8Wz9W 
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Now the GitLab Runner is registered and listed at https://<GitLab-URL>/admin/runners.

Debugging

If we run a pipeline at this point, we notice that the job runs into a timeout during a git command. Here it is helpful to do a deep debugging. On the one hand we can add the following line in the file C:GitLab-Runnerconfig.toml under our selected runner:

environment = [“GIT_CURL_VERBOSE=1”, “GIT_TRACE=1”]

Furthermore, we can put the CI job into debug mode, which must be switched off for production readiness.

gitlab-ci.yml

job_name:
  variables:
    CI_DEBUG_TRACE: "true"

Configure Git

The reason the Runner runs into a timeout, as mentioned above, is a configuration in Git. Let’s output the git configuration:

PS C:GitLab-Runner> git config --list

core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=helper-selector

Under credential.helper we need the value manager instead of helper-selector. The following commands are used for this.

PS C:GitLab-Runner> git config --system --unset credential.helper helper-selector
PS C:GitLab-Runner> git config --system --set credential.helper manager
PS C:GitLab-Runner> git config --list

core.symlinks=false
core.autocrlf=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager

Finally we start the GitLab-Runner service and check and reviewi ts status. Now our CI pipeline is able to build windows containers using the GitLab Runner installed on our windows host.

PS C:GitLab-Runner> .gitlab-runner.exe start
Runtime platform                                    arch=amd64 os=windows pid=3692 revision=de7731dd version=12.1.0

PS C:GitLab-Runner> .gitlab-runner.exe verify
Runtime platform                                    arch=amd64 os=windows pid=3432 revision=de7731dd version=12.1.0 
Verifying runner... is alive                        runner=TM_9eM-x

We hope you enjoyed our tutorial and you try it out. We are looking forward to your feedback.

If you would like to know more about Kubernetes and its terms, please browse our knowledge base or visit us at OWL Tech und Innovation Day on 26.09. in Paderborn.

See you soon at “Kubernetes and me”

Install Windows GitLab Runner