I tried to create an exact copy of of our default SonarQube quality profile by clicking on the "Copy" link in the "Quality Profiles" page, but some of the rules are not copied. We use SonarQube version 4.5.6 and the profile I tried to copy does not inherit from any other profiles.
According to the SonarQube documentation, the new profile is an exact copy of the original profile, including inheritance (parent) relationships. However, my copied profile is missing the following 9 rules out of 487 and I don't see any reason why (they are all 'checkstyle' rules, but there's many more with the same label that got copied correctly):
Boolean Expression Complexity (checkstyle)
Comment pattern matcher (checkstyle)
Constant Name (checkstyle)
Hidden Field (checkstyle)
Inner Assignment (checkstyle)
Local Variable Name (checkstyle)
Magic Number (checkstyle)
Member name (checkstyle)
Static Variable Name (checkstyle)
The rules you name are all template rules, i.e. rule "cookie cutters" from which you can stamp many rule variations. Unfortunately, rules created from templates, a.k.a. "custom rules", aren't properly handled in profile backup and restore.
This is currently scheduled for the 6.x series. The Jira ticket is SONAR-5366.
Related
I wanted to configure my SonarQube [v8.9.6.50800] scan to ignore Specific rule e.g. squid:S1172 from classes which contains a specific string e.g. implements BillingApi.
To set this up I need to use some configuration?! that will accept a regular expression, let's say: .* implements [^{]*Api and rule.
I'm aware of the option to exclude specific rule for file path pattern as explained here: SonarQube define "Ignore Issues on Multiple Criteria" in maven build
Or the option to exclude all rules in a file as explained here: sonar project.properties to ignore files containing a regular expression
But I need to narrow the scope to exclude specific rule from file contains some regex.
Instead of excluding or ignore rules in sonar's property file, I'd like to have only a few certain rules for sonar to analyse, so I don't need to exclude a large number of rules out of 344 rules for c++. How can I do that? (I'm not adding customized rules)
I imageine the syntax would be: (in .properties file)
sonar.issue.include.multicriteria=***
sonar.issue.include.multicriteria.***.ruleKey=cpp:S984
....
EDIT:
1, I need to configure this in a CLI environment.
2, It's about one project, two rule sets. one rule sets for local use and the other one for CI/CD use.
You need to craft a Quality Profile that contains only your rules of interest, and then either make it the default profile for C++, or explicitly assign your project to it.
BTW, correctly setting exclusions in properties (versus through the UI) is quite tricky. I'm not sure about the correctness of the ruleKey field name, and you're probably missing another field in there, but your syntax seems to be on the right track.
I once had an extra filter for all rules/problems, whose issues had been fixed up completely in the project, so I would easily see new ones regarding these rules (issue count of that filter rises from 0 to ...).
With version 6.3.1 filters are not supported anymore, so I created a quality profile including the same rules.
My problem is that it's only possible to activate 1 single quality profile for the project, so I can't filter these rules anymore. I also tried to use a parent quality profile, without success. The solved issues of the rules are completely in the 'normal' quality profile, if that's of importance.
How can I configure SonarQube, so that the system analyses 2 quality profiles on the same project?
I read of a work around that just creates a second branch of the project to analyse that one, but I am seeking out for a cleaner solution.
Example:
Quality Profile 'fixed rules':
count 0: use diamond operator
count 0: no stupid equality checks
Quality Profile 'all activated rules':
count 0: use diamond operator
count 0: no stupid equality checks
count 100: variable does not match pattern xyz
count 500: switch case without default
...
It's not possible to add another quality profile. Actually, the project only needs to be analyzed once.
Why don't you just set the tag 'fixed' to all your solved rules? Then you can easily filter the issues with that tag and see the results.
Suppose I have set groupId to com.example, and artifactId to fancy.project, and now I want to create a archetype, such that when created, expands into the following structure:
|--src
|--main
|--com
|--example
|-fancy
|-project
|-App.java
That is, I wonder how to expand a variable into a nested directory.
I understand that the dual-underscore-wrapped variables will be substituted in file/directory names, but I can only get the following with __groupId__.
|--src
|--main
|--com.example
|-fancy.project
|-App.java
As input to the archetype you can specify the package option (which would then follow your input, the groupId and artifactId concatenation if you want, even though it is not always the case and hence provide even more flexibility).
Then, in your archetype you can use the packageInPathFormat option (available since archetype 2.2) which would replace any dot . into slash \ and as such transforming it to a path into the generated project.
However, the option is not officially documented (pity) even though supported and works fine for such a scenario.
Looking at the code, the DefaultFilesetArchetypeGenerator and its getPackageInPathFormat provide the concerned transformation from the package option to a path, while the org.apache.maven.archetype.common.Constants.PACKAGE_IN_PATH_FORMAT is the official entry point for this option.
Some externals pointers on the usage of this option:
http://geekofficedog.blogspot.be/2013/08/creating-maven-archetypes-tutorial.html
http://www.theotherian.com/2012/05/maven-archetypes-part-2-how-do-i-create.html
To further explain:
You can have the __packageInPathFormat__ folder under your src/main/java, for example
The __packageInPathFormat would then be replaced by the package option transforming dots into slashes
The package option has a default value to groupId, so if you don't specify it, for a groupId with value com.sample, the path would be com/sample
You can hence specify at invocation time the package desired via -Dpackage=your.package repeating the values for -DgroupId and -DartifactId (a bit verbose and error prone though), the final result will actually be what you expected (transformed to correct path).
You can specify new default values via a archetype-metada.xml file, as specified in the official documentation, via the requiredProperties section, you could have something like:
<requiredProperties>
<requiredProperty key="package">
<defaultValue>__groupId__.__artifactId__</defaultValue>
</requiredProperty>
</requiredProperties>
However, the generated path would then be com.sample/artifactid rather than com/sample/artifactid. Hence it would not work as expected due to the processing workflow which would replace the placeholders after transforming it to a path (pity!).
(Note: it would transform the dot we provided as configured value, but would then not transform dots into the replaced placeholders).
As of a quick code analysis, seems like the DefaultFilesetArchetypeGenerator class in its generateArchetype method is preparing the context too early (in its prepareVelocityContext method, where the packageInPathFormat is transformed and added to the context), then the context is passed to processArchetypeTemplate* methods which would eventually invoke the Velocity engine (which is going to replace placeholders then). I am not a Velocity expert though, hence I may miss some glue, but the observed behavior and the code workflow seem to lead to this conclusion.
Instead of using the variables __groupId__ and __artifactId__ you can use ${groupId} and ${artifactId} respectively instead (I don't know if these were around when this question was posted), so it would look something like this:
<requiredProperties>
<requiredProperty key="package">
<defaultValue>${groupId}.${artifactId}</defaultValue>
</requiredProperty>
</requiredProperties>
When generating a project using these, in interactive mode it will actually request to enter the package, and in batch mode it will automatically generate CLOSE to what OP wanted.
Ex. groupId being me.zenisbestwolf and artifactId being fancy-app will generate the path of me/zenisbestwolf/fancy-app. Unfortunately automating the artifact ID to go from fancy.app to fancy/app like OP wanted to isn't possible without manually defining the package, AFAIK.
is there a possibility to duplicate existing checkstyle rules? I want Sonarqube to differ guideline rules.
Example:
The rule for method complexity should mark the method as [MINOR] when there is more than 10 lines of code per method and as [MAJOR] when there is more than 30 lines of code per method.
Maybe there is a particular plugin for this special case?
Thanks in advance
This is currently a limitation in SonarQube. However, it can be done partially.
For Checkstyle based rules, you can copy some rules (those that have a Copy Rule button; screenshot here under "Multiple activation of rules"). I've personally used this for the Comment Pattern Matcher and created a rule that matches TODO comments as INFO severity and another that matches FIXME comments as CRITICAL. As I understand your question, that is what you are looking for. I don't think this is possible for all parameterizable rules, though.
Also, for PMD based rules, there is this blog post which describes how to use the XPath rule template in order to create custom PMD rules. This could be a workaround for those PMD based rules that don't have a Copy Rule button.
The feature we would need is a Copy Rule button for every parameterizable rule. AFAIK, this does not exist yet.