Continuous Integration and Implementation, or CI / CD, is the process of streamlining and accelerating development by automatically building and testing every commitment to your project. GitLab integrates CI / CD into their
git solution extremely well, and we’ll show you how to set it up and work with it.
Setting up a build server (GitLab Runner)
Often times compiling code can be an extremely intensive operation. Not all languages have this problem, but some, such as C ++, can take more than half an hour to complete a complex build. For example, Chromium can last over an hour even on 1
Time is money, so many companies will choose to build dedicated servers, often a swarm of servers, and run their CI / CD pipelines on powerful hardware.
If you’re not self-hosting, and instead use GitLab’s online SaaS solution (gitlab.com), you’ll have to pay for CI / CD minutes. The free tier includes 400 CI / CD minutes, which should be enough for simple projects, especially languages like JS, where all that might be needed is a basic project.
npm build. The higher tiers, charged per user, provide much more build time. You can view the current totals on the GitLab pricing information page.
In our case, we are self-hosting, so we will have to set up a GitLab Runner, which will be installed on a server and configured as a build agent. This is available as both a binary and a Kubernetes deployment, which can be ideal for autoscaling multi-server deployments.
Fortunately, the installation process is simple. You need to find out which binary file you need for your host and download it. For Debian based systems such as Ubuntu, the
curl -LJO "https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb"
And install it with
sudo dpkg -i gitlab-runner_amd64.deb
Then you need to configure it with the URL and token in / admin / runners.
sudo gitlab-runner register
You will be asked to specify which performer should use this runner. In most cases you can just use “docker”, with a default image like ubuntu.
Once configured, you can start the runner:
sudo gitlab-runner register
Then you should see it in the list.
In our case, there was a weird bug where the runner wouldn’t start because the
/var/lib/gitlab-runner folder was not present. Making it manually solved the problem immediately:
sudo mkdir /var/lib/gitlab-runner
You need to open the settings for the runner and set the appropriate tags for it which will be picked up by matching gitlab-ci.yml configuration files. If you don’t bother with tags instead, you can check this box here to get untagged tasks:
Then you need to configure your projects to use this runner.
Set up CI / CD for your project
You configure GitLab CI with a file in the root of your project, called
.gitlab-ci.yml. This is automatically used to run.
The exact configuration of this depends very much on you and your needs, of course. A good place to start is to look up how others have fared for your language and runtime.
For example, a simple .NET build can be done with a configuration like the following:
image : microsoft/dotnet:latest stages: - build before_script: - 'dotnet restore' build: stage: build script: - 'dotnet build'
First, we need to set the Docker image that GitLab will use to build your application. This is important because otherwise the environment will not have a .NET runtime. Everything revolves around
dotnet restorethen run
dotnet build to actually build the application.
To learn more about the structure of this file, please refer to the GitLab documentation.
Once assigned to your repo, that commit will trigger the first pipeline. You can view pipeline results under CI / CD> Pipelines, where you will see each run next to its status.
Clicking on the details will help you debug during a failed execution as it keeps a log of the console.