Go (or Golang) is a new language (less than 10 years old). It is already widely used by some impressive parties, such as Docker (https://docker.com), Google, Kubernetes (https://kubernetes.io), and Prometheus (https://prometheus.io). Go is a versatile tool that can help you to program at a low level, close to the operating system or at a high level in a language such as Java. It is perfectly suited to creating systems software. The language was created in 2009 by R. Griesemer, R. Pike, and K.Thompson while working for Google. The latter is very famous for co-creating the first Unix implementation and the B programming language. The most important feature of the Go language is that it can compile one binary without dependencies for multiple operating systems such as Linux, macOS, the BSDs, and Windows. This also means it runs on different processor architectures (i386, amd64, ARM, and PowerPC).

A short list of the benefits of Go follows:

• Very good standard libraries (with good optional ones available elsewhere).
• It is very fast to develop and test in Go.
• The culture/community chooses boring solutions over complex ones (which is good).
• Cool tools such as Gofmt, race detector, and go vet.
• Made for concurrency—for instance, you can use goroutines and channels.
• Type safety—will save you many times from run-time errors and wrongly defined data types.
• Garbage collection—while programmers who use C know how to clean up, this can still be helpful.
• Closures or anonymous functions—enable the use of functional principles (higher-order functions).

All these characteristics make Go the perfect choice for GitLab Runners. With Go, you can create a relatively small binary that runs on a lot of platforms. It contains all that is needed to run your projects.

In a GitLab environment, jobs are being executed by the Runners. They run them as they are defined in a .gitlab-ci.yml file. The Runner itself can be running on a Virtual Machine (VM) such as VmWare (VM), VPS, a laptop, a Docker container, or in a Kubernetes cluster. Communication is one way from runner to GitLab and is mostly via an HTTP API, so that path must be accessible by the Runner.

The .yml file defines what stages your CI/CD pipeline has and what to do in each stage. This typically consists of build, test, and deploy stages.

The project can be found at https://gitlab.com/gitlab-org/gitlab-runner:

A runner can either be specific to a certain project or it can serve multiple projects in GitLab. If it serves all projects, it's known as a Shared Runner. GitLab Runners implement a number of executors that can be used for your builds in different scenarios:

• Shell executor: The runner simply executes a shell. The dependencies for the build have to be installed manually.
• Docker-based executor: The runner runs from a container. This makes it easier to create clean builds because dependency management is shifted to the container image. It is also easier to create a build environment with services that need each other, such as PostgreSQL.
• Autoscaling Docker SSH: A Docker machine creates instances with the Docker Engine to run Docker containers.
• Kubernetes: GitLab Runner can use Kubernetes to run builds on a Kubernetes cluster.

Runners have evolved enormously over the last couple of years. GitLab itself sees them as one of the most important components of their suite. This section has given more insight into the development of this popular tool.