During this tutorial, I assume that you have finished the “SonarScanner for MSBuild tutorial” and you have your SonarQube server, sonar scanner and example project sets and ready to play with. If not please check the previous tutorials for instructions.

Keep in mind this article is part of our series on SonarQube!

1. SonarQube tutorial – how to get started?
2. SonarScanner tutorial
3. SonarScanner for MSBuild tutorial
4. Rules, quality profiles and quality gates (you’re here!)
5. Gitlab integration tutorial

Quality profiles

Overview

The Quality Profiles service is central to SonarQube since this is where you define your requirements by defining sets of rules (ex: Methods should not have a Cognitive Complexity greater than 15).

Ideally, all projects will be measured with the same profile for any given language, but that’s not always practical. For instance, you may find:

The technological implementation differs from one application to another (for example, different coding rules may apply when building threaded or non-threaded Java applications).

You want to ensure stronger requirements on some of your applications (internal frameworks for example).

Etc.

Sonarqube Quality Profiles official documentation.

Quality profiles practical example

Let’s assume that our example .NET project from the previous tutorial requires the creation of  some rules customization due to used solutions for C# profile.

Firstly we should create a copy of the C# profile and name it SONAR_NET_PROJECT way to keep naming in our example solution in order under this URL http://localhost:9000/profiles.

Then associate a new quality profile with our project.

In our example project, we want to be able to throw general exceptions and this is causing a lot of rule violations for us.

http://localhost:9000/project/issues?id=SONAR_NET_PROJECT_KEY&resolved=false&rules=csharpsquid%3AS112

In order to address this, let’s use our new profile and select active rules.

Then search for a rule that we want to address: General exceptions should never be thrown and deactivate it.

In root directory of our .NET example project run docker build --network=host --no-cache . to analyse project using our new Quality profile SONAR_NET_PROJECT way.

The deactivated rule should no longer be taken into consideration for our project.

http://localhost:9000/project/issues?id=SONAR_NET_PROJECT_KEY&resolved=false&rules=csharpsquid%3AS112

In custom profiles, it is possible to change every rule Severity according to our needs and for some rules to set values for given options.

Quality gates

Overview

A quality gate is the best way to enforce a quality policy in your organization. It’s there to answer ONE question: can I deliver my project to production today or not?

In order to answer this question, you define a set of Boolean conditions based on measurement thresholds against which projects are measured. For example:

No new blocker issues

Code coverage on new code greater than 80%

Etc.

Ideally, all projects will be verified against the same quality gate, but that’s not always practical. For instance, you may find:

Technological implementation differs from one application to another (you might not require the same code coverage on new code for Web or Java applications).

You want to ensure stronger requirements on some of your applications (internal frameworks for example).

Etc.

Which is why you can define as many quality gates as you wish. Quality Gates are defined and managed in the Quality Gates page found on the top menu.

Sonarqube Quality Gates official documentation

Quality gate practical example

Let’s assume that the Default Quality gate “Sonar way” isn’t strict enough for our project, so we should create a new quality gate.

Enter http://localhost:9000/quality_gates and press the copy button as shown below.

Let’s name it Strict way and assign it to our project as shown below.

We don’t want to have any tests skipped, so we add the new condition Skipped Unit Tests and set its threshold value to 0 as shown below.

We don’t want to have any test failures, so we add the new condition Unit Test Failures and set its threshold value to 0 as shown below.

Now execute analysis again and check the result in the server dashboard http://localhost:9000/dashboard?id=SONAR_NET_PROJECT_KEY. The quality gate is still passing, isn’t it?

Let’s seed out a project with some invalid tests then!

Edit  tests\UnitTests\ApplicationCore\Services\BasketServiceTests\DeleteBasket.cs file by adding following code to it:

 
        [Fact(Skip = "skipped!")]
        public void Should_Be_Skipped()
        {
            throw new System.Exception();
        }

        [Fact]
        public void Should_Throw_Exception_And_Fail()
        {
            throw new System.Exception();
        }

Save changes and edit Dockerfile by changing Run dotnet test … to RUN dotnet test --logger "trx;LogFileName=TestResults.trx" /p:CollectCoverage=true /p:CoverletOutputFormat=opencover; exit 0

Run an analysis. You should see a failed quality gate as in the screen below.

Branches – developer edition

[Obsolete since SonarQube 7.7]

It is also worth mentioning that in the current version of pull request and short branch analysis feature in SonarQube server it is always using hard-coded Quality gate instead of one that is chosen for the project. Quality gate of our choice is executed only during analysis of long living branches.

Release of SonarQube 7.7 adds support of full quality gates for pull requests and short living branches.

What next?

We will wrap things up with the Gitlab integration tutorial, which will show us how to integrate SonarQube with pull requests.

Cleaning up after tutorial

To stop a container with running SonarQube server instance run following command: (don’t do this if you want to continue with the next tutorial!)

docker container stop sonarqube

To remove also all docker containers run

docker container prune --force

Finally to remove all images used in this tutorial run

docker image remove sonarqube:7.5-community sonar-scanner-image