After configuring our first PL/SQL analysis from Jenkins, we launched it, so we can now look at the results in the SonarQube dashboard.
This will be an opportunity to discuss and explain, in our next posts, the PL/SQL best practices proposed by SonarQube. But first, let’s have a look at the rules we get with the SonarQube PL/SQL Quality Profile.
Let’s remember that a Quality Profile is a set of rules, each with a weight (Blocker, Critical, Major, etc..). We can customize this profile by enabling or disabling some rules, or assigning a different level of severity based on the best practices adopted by the project team or the customer. Usually, everybody knows the most important rules, so they are mandatory and cannot be unactivated, although it may be possible sometimes to change their weight. Other rules, generally less critical, can be disabled if a customer has chosen not to include them in its own best practices.
To make these choices, let’s look at the SonarQube Quality Profile
The SonarQube PL/SQL Quality Profile
We can see 17 Blockers but zero Critical. Surprising!
It is quite possible to have only 17 Blockers, as a possible consequence of some lack of attention from the project team, but a perfect score on the Critical rules with a total absence of faults is really amazing.
Let’s have a look to the default SonarQube Quality Profile. To do this, we activate the corresponding menu in the menu bar to open the page of the same name.
Click on this link to enter into the page detailing these rules. We will first search for the set of Critical rules by selecting ‘Critical’ in the combo-box ‘Severity’, then pushing the ‘Search’ button.
Then we can see that this Profile has only 5 rules ‘Critical’ and they are all disabled, since none is selected.
We can see that 58 rules are disabled, in addition to the existing 74.
Certainly not all rules are necessarily applicable, but let’s remember that my objective in this series of posts is to build a demo that allows me to show what SonarQube can do in assessing the quality of PL/SQL code, and how to achieve an audit of this code with SonarQube. For that, I want to have the largest number of rules, even if I may then disable some rules or change their criticality.
Create a new Quality Profile
So I will create a new Quality Profile in which I will ll activate all the existing rules. I can then re-run my PL/SQL analysis and see in the dashboard if I get interesting results.
In order to create a new profile, I must first of all connect as an ‘Admin’, so that when I return to the ‘Quality Profile’, new menus are displayed that allow me to copy the default profile by clicking on the ‘Copy’ menu.
A dialog box appears that allows me to specify a name for the new Profile.
Once it is created, we enter this Profile page and search all inactive rules, as we have done previously.
And once all the 58 inactive rules are displayed, I can activate all of them with the ‘Bulk Change’ in the upper right of the screen. Simply select ‘Activate all’ and all the rules present in the screen are enabled.
Now SonarQube tells me that 132 rules are available in my new profile: the originally active 74 and the 58 we just enabled. The count is right.
Once this is done, I’ll logout as Admin and go to Jenkins to launch a new PL/SQL analysis.
We now are able to see all PL/SQL rules available with SonarQube, and customize our new Quality Profile.
The next post will be dedicated to the most important rules: ‘Blockers’ and ‘Critical’. See you soon!