This article covers the configuration of a CI pipeline for a C++ challenge on GitLab. My earlier articles lined the way to arrange a construct system based mostly on CMake and VSCodium and the way to combine unit checks based mostly on GoogleTest and CTest. This article is a follow-up on extending the configuration by utilizing a CI pipeline. First, I show the pipeline setup after which its execution. Next comes the CI configuration itself.
Continuous integration (CI) merely implies that code adjustments, which get dedicated to a central repository, are constructed and examined routinely. A well-liked platform within the open supply space for organising CI pipelines is GitLab. In addition to a central Git repository, GitLab additionally presents the configuration of CI/CD pipelines, concern monitoring, and a container registry.
Terms to know
Before I dive deeper into this space of the DevOps philosophy, I’ll set up some widespread phrases encountered on this article and the GitLab documentation:
- Continuous supply (CD): Automatic provisioning of purposes with the purpose of deploying them.
- Continuous deployment (CD): Automatic publishing of software program
- Pipelines: The top-level element for CI/CD, defines levels and jobs
- Stages: A set of jobs that should execute efficiently
- Jobs: Definition of duties (e.g., compile, performing unit check)
- Runners: Services which might be really executing the Jobs
Set up a CI pipeline
I’ll reuse the instance initiatives from earlier articles, which can be found on GitLab. To observe the steps described within the coming chapters, fork the example project by clicking on the Fork button, which is discovered on the highest proper:
Set up a runner
To get a sense for a way every little thing works collectively, begin on the backside by putting in a runner in your native system.
Follow the installation instructions for the GitLab runner service to your system. Once put in, it’s a must to register a runner.
1. On the GitLab web page, choose the challenge and within the left pane, navigate to Settings and choose CI/CD.
2. Expand the Runners part and change Shared runners to off (yellow marker). Note the token and URL (inexperienced marker); we want them within the subsequent step.
3. Now open a terminal and enter gitlab-runner register. The command invokes a script that asks for some enter. Here are the solutions:
- GitLab occasion: https://gitlab.com/ (screenshot above)
- Registration token: Pick it from the Runners part (screenshot above)
- Description: Free selectable
- Tags: This is non-compulsory. You needn’t present tags
- Executor: Choose Shell right here
If you need to modify the configuration later, yow will discover it underneath ~/.gitlab-runner/config.toml.
4. Now, begin the runner with the command gitlab-runner run. The runner is now ready for jobs. Your runner is now out there within the Runners part of the challenge settings on GitLab:
Execute a pipeline
As beforehand talked about, a pipeline is a group of jobs executed by the runner. Every commit pushed to GitLab generates a pipeline connected to that commit. If a number of commits are pushed collectively, a pipeline is created for the final commit solely. To begin a pipeline for demonstration functions, commit and push a change immediately over GitLab’s internet editor.
For the primary check, open the README.md and add a further line:
Now commit your adjustments.
Note that the default is Create a brand new department. To hold it easy, select Commit to essential department.
A number of seconds after the commit, it’s best to discover some output within the console window the place the GitLab runner executes:
Checking for jobs... acquired job=1975932998 repo_url=https://gitlab.com/hANSIc99/cpp_testing_sample.git runner=Z7MyQsA6Job succeeded duration_s=3.866619798 job=1975932998 challenge=32818130 runner=Z7MyQsA6
In the challenge overview in GitLab, choose on the appropriate pane CI/CD –> Pipelines. Here yow will discover a listing of just lately executed pipelines.
If you choose a pipeline, you get an in depth overview the place you’ll be able to verify which job failed (in case the pipeline failed) and see the output of particular person jobs.
A job is taken into account to have failed if a non-zero worth was returned. In the next case, I simply invoked the bash command exit 1 (line 26) to let the job fail:
CI configuration
The levels, pipelines, and jobs configurations are made within the file .gitlab-ci.yml within the root of the repository. I like to recommend modifying the configuration with GitLab’s build-in Pipeline editor because it routinely checks for accuracy throughout modifying.
levels:
- construct
- check
construct:
stage: construct
script:
- cmake -B construct -S .
- cmake --build construct --target Producer
artifacts:
paths:
- construct/Producer
RunGTest:
stage: check
script:
- cmake -B construct -S .
- cmake --build construct --target GeneratorTake a look at
- construct/Generator/GeneratorTake a look at
RunCTest:
stage: check
script:
- cmake -B construct -S .
- cd construct
- ctest --output-on-failure -j6
The file defines the levels construct and check. Next, it defines three jobs: construct, RunGTest and RunCTest. The construct job is assigned to the eponymous stage, and the opposite jobs are assigned to the check stage.
The instructions underneath the script part are bizarre shell instructions. You can learn them as for those who had been typing them line by line within the shell.
I need to level out one particular function: artifacts. In this case, I outline the Producer binary as an artifact of the construct job. Artifacts are uploaded to the GitLab server and might be downloaded from there:
By default, jobs in later levels routinely obtain all of the artifacts created by jobs in earlier levels.
A gitlab-ci.yml reference is on the market on docs.gitlab.com.
Wrap up
The above instance is an elementary one, but it surely exhibits the overall precept of steady integration. In the above part about organising a runner I deactivated shared runners, though that is the precise energy of GitLab. You can construct, check, and deploy your software in clear, containerized environments. In addition to the freely out there runners for which GitLab supplies a free month-to-month contingent, you too can present your personal container-based, self-hosted runners. Of course, there may be additionally a extra superior manner: You can orchestrate container-based runners utilizing Kubernetes, which lets you scale the processing of pipelines freely. You can learn extra about it on about.gitlab.com.
As I’m working Fedora, I’ve to say that Podman shouldn’t be but supported as a container engine for GitLab runners. According to gitlab-runner concern #27119, Podman assist is already on the listing.
Describing the recurring steps as jobs and mixing them in pipelines and levels lets you hold observe of their high quality with out inflicting further work. Especially in massive group initiatives the place it’s a must to determine whether or not merge requests get accepted or declined, a correctly configured CI strategy can let you know if the submitted code will enhance or worsen the challenge.