The "Quality Profiles" service is the nervous center of Sonar. It enables to define the various sets of source code requirements that should be used when measuring the quality of projects. It also enables to define acceptable thresholds on measures and to trigger alerts when they are reached.
A source code requirement is materialized by a coding rule in Sonar that is active, configured and has a severity. Here is an example : "A method must not have a complexity greater than 10!". Out of the box, Sonar embarks for the Java language several coding rules (requirements) engines : Checkstyle, PMD and Findbugs. Is also provides its own engine for advanced requirements. This represents more than 700 rules in total.
A quality profile is a set of source code requirements. Sonar enables to define several quality to fit various types of projects. Indeed, the requirements are usually not the same when starting to develop from scratch an application or when maintaining an application which is 10 years old, when developing a technical library or a web application. A quality profile is also a set of visual alerts on measures. Here is an example of alert : "Highlight the complexity by method measure in the project's dashboard when this complexity by method is greater than 3."
Here is the entry page of the "Quality Profiles" service :
The "Quality Profiles" service can be accessed by anonymous users but changes require to be logged in as an administrator.
Create a profile
To create a quality profile, click on "Create" button on the upper right and enter the name of the quality profile :
You can optionally provide some Checkstyle, PMD and Findbugs configuration files to fill the new quality profile with some existing rules configurations.
Copy a profile
In order to copy an existing quality profile, click on the "Copy" button next to the profile you want to copy. You are prompted to give the name of the new profile. The profile is the exact copy of the copied one. You can then make desired changes to the new quality profile.
Delete or rename a profile
Click on the "Delete" or "Rename" buttons :
Deleting a quality profile, will delete the alerts defined in the profile and will remove the association with projects. If nothing else is done , Sonar will use the default profile to perform the next analysis on the (ex-)associated projects.
Edit a profile
The rules configuration tab is the default page where you land when entering a profile. As there are numerous rules available, a very handy search engine is available in the rules configuration screen to filter only the one to configure :
A rule can be activated or deactivated in a single click. Its severity and configuration in the profile can be changed as soon as it is activated.
Some "Bulk Change" actions are also available to quickly activate or deactivate a set of rules. For instance, you can easily add all Findbugs rules to an existing quality profile by : selecting this profile, searching for Findbugs rules and launching "Activate all" action :
Multiple activations of a rule
Some rules can be activated multiple times in the same quality profile with different parameter's values. Checkstyle "Regexp Singleline" rule and PMD "XPath" rule are those kind of rules.
If a rule can be activated multiple times, a "Copy" button is available at the end of the rule description :
Clicking on the "Copy rule" button displays a form to define the new rule from the parent one :
Once the new rule has been created, it can be managed as any other rules :
To manage alerts configuration, you should use the "Alerts" tab :;
From there it is possible to fully manage alerts, by adding new one, editing or deleting existing alerts. The principle is the following :
- Choose the metric you are interested in
- Choose an operator (is greater than, is less than)
- Choose the value that will trigger a warning
- Choose the value that will trigger an error
Any change to alerts will be used when the next analysis is performed
Maintaining Quality Profiles can be tedious over time, especially where there are many. To ease maintenance of profiles, the ability of inheriting from a profile was added in Sonar 2.5. The principle is that for a custom profile, you can decide that it is going to have a parent profile by using the Profile Inheritance tab :
This means that the quality profile inherits all rules defined in the parent. This is shown visually in the rules configuration screen by a small blue marker next to the rule :
A rule inherited from a parent cannot be de-activated but it is possible to change its parameter(s) and / or is severity. As soon as one of those is changed, a red marker replaces the blue marker
To revert the changes done on an inherited rule,
To associate a project to a quality profile, you can use the "Projects" tab :
The projects associated to a profile will appear in the right hand box. It is possible to move projects around by selecting them and use one of the 4 actions listed. A project can be associated to only one profile at the time. When a project is not explicitly associated to a quality profile, Sonar uses the default quality profile to perform the next analysis.
This backup/restore mechanism is useful for instance to promote a quality profile from a test environment to a production environment or to share quality profile with contractors.
Click on the "Backup" button to export an XML file :
To restore a quality profile, click on the "Restore profile" link on the upper right of the "Quality profiles" page, choose the XML file to restore and click on the "Restore profile" button :
Checkstyle and PMD provide extension mechanisms to develop custom coding rules. Tutorials to write such custom coding rules are available online for both Checkstyle and PMD. You can for instance define your own naming conventions, forbid access to a given API or anything else that is relevant in your context.
Once this is done, you must feed the Sonar web server with those coding rules extensions. Here are the process to follow for both Checkstyle and PMD coding rules.
The Checkstyle coding rules must be packaged in a JAR file and this file must be copy in the $SONAR_HOME/extensions/rules/checkstyle/ directory.
A XML file must then be created in the same $SONAR_HOME/extensions/rules/checkstyle/ directory to "index" all available custom rules implemented in the JAR file. The name of this XML file doesn't matter but the .xml suffix must be used.
This XML file must look like the following example :
The PMD coding rules must be packaged in a JAR file and this file must be copy in the $SONAR_HOME/extensions/rules/pmd/ directory. Moreover, the JAR file must also contain the PMD ruleset XML file (in the following example, this XML file will be available through the classloader with the following path : rulesets/myruleset.xml)
A XML file must then be created in the same $SONAR_HOME/extensions/rules/pmd/ directory to "index" all available custom rules implemented in the JAR file. The name of this XML file doesn't matter but the .xml suffix must be used.
This XML file must look like the following example :
Since Sonar 2.3, it's now possible to define XPath rules directly into this XML file without any need to provide an additional jar file. Here is an example of an XPath rule defintion :