Introduction: GÉANT Project GitLab
GitLab is an open-source code hosting platform for collaboration and version control. It can be installed on your servers to host your codes privately. GitLab provides Source Code Management (SCM) functionality similar to GitHub and BitBucket.
GÉANT Project GitLab is the instance of GitLab used by the developers in the GÉANT communities and GitLab CI/CD is a tool built into GitLab for software development of CI/CD pipelines.
It allows performing a defined task upon a list of defined actions. By default, every action on the repository triggers a task (commit, merge, tag creation), but the user is entitled to restrict the number of actions.
For the correct trigger of the SonarQube task, GitLab CI uses a "runner" that is already configured in our GÉANT Project GitLab deployment. Momentarily the runner is configured as a "shared" process (shared runner). This means that one runner is used to trigger the SonarQube analysis for all GitLab projects that use the CI/CD pipeline. For this, the runner queues all incoming requests and works on them in a sequential way. In the past, not many projects were using SonarQube at the same time. Therefore, we assume that momentarily the usage of the "shared runner" will have no impact on the processing time of your project in SonarQube.
Create a token in SonarQube
You need to have a token to authorize the CI against SonarQube. In fact, the CI must be able to push the outcome of the scan to SonarQube.
You'll use the token to provide a value for the variable SONAR_LOGIN (see the point: 4.2 Project Variables).
You can create a personal token under the security settings of your SonarQube account (My Account → Security):
Setup your project in the GÉANT deployment of GitLab
Create your project in the GÉANT Project GitLab deployment.
As the creator of the project, you usually have the member permissions for the Owner role. If you want other team members to access and change the variables and the runner they must be either Maintainer or Owner of this project. Otherwise, they only need a role authorized to commit and push to the repository (e.g. Developer).
With your member permission set to Owner or Maintainer the aforementioned "runner" information will be visible to you in the "Shared runners" section, similar to the following picture (Settings → CI/CD → Runners):
The tag name is "sonarqube" and the runner is intended to be a Docker runner.
Configure your GitLab Project
To enable GitLab to automatically execute the CI/CD runner, some variables need to be defined. Some of them had already been set on a global ("system") level, others must be set by your project.
The following two variables are required. They are already set up globally in GitLab, so that you don't need to define them again.
- SONAR_HOST_URL = https://sonarqube.software.geant.org
- SONAR_SCANNER_CLI_VERSION = 4.6
The user will have to set a token variable at the project level (Settings → CI/CD → Variables → Add Variable - it is recommended to use a "masked" type of variable).
- SONAR_LOGIN = XXXXX-XXXXX-XXXX
The value of SONAR_LOGIN must be identical to the value of the SonarQube token as defined in Step 2.1 Create a token in SonarQube.
Create the file .gitlab-ci.yml
The file that is responsible to define the appropriate list of tasks that need to be executed after a "git push" is the file .gitlab-ci.yml. This file must be placed in the root directory of your project.
If the file is absent, the CI is skipped (i.e.: SonarQube won't be triggered).
Some of the variables used in the YAML file are based on other existing variables already defined before. They are listed to give you a detailed understanding but they don't require any action (definition or adaptation) from your side.
- SONAR_SCANNER_CLI_VERSION (see step 2: it's defined globally).
- CI_PROJECT_DIR: points to the root directory of your project (it's a built-in variable and it cannot be changed).
- CI_PROJECT_NAME: corresponds to the name of the project and this same name will be assigned to the SonarQube project (it's a built-in variable and it cannot be changed).
GitLab CI extra settings
The CI will trigger SonarQube on each event by default (commit to every branch, tags creation, merge...). It's up to the user to limit the triggers for the CI or skip the CI on certain branches.
To restrict the triggers, the user can play with the
rules parameter: https://docs.gitlab.com/ee/ci/yaml/README.html#rules in conjunction with the
if clause, as explained in the documentation.
Step 3: Check SonarQube dashboard
Also, you can see the project code reports from within SonarQube.
That’s it! You have successfully integrated GitLab and SonarQube.
the following script is run by the container to trigger the SonarQube.
- GÉANT instance of SonarQube
- Information regarding GÉANT instance of GitLab GitLab - Source Code Repository