Support specifying rule type and adding tags

[koczkatamas]

Adds two command line parameters:

• "/addTag:" which adds the <tag> to all rules
• "/ruleType:CODE_SMELL|VULNERABILITY|BUG" allows to set all rules' type to other than the default code smell

Please note this is a preliminary PR which does not includes eg. tests for the new functionality and may violate some Sonar rules (eg. allowed parameter count in a method signature), so let's discuss first what requirements needs to be satisfied before going forward.

[duncanp-lseg]

Hi @koczkatamas. Thanks for submitting the PR, and apologies for the delay in responding.
What's the scenario that you want to support? Is it to add metadata to an analyzer that you are developing yourself, or are you wrapping a third-party analyzer?

At one point in the past we had an internal discussion about the possibility of using custom tags or attributes on the analyzers to specify the additional rules metadata, which would be a more flexible solution for analyzer authors.
For users wrapping a third-party analyser, we considered a similar approach to that used for the SQALE information i.e. generating a default rules.xml file on the first run that the user could then edit and provide to the plugin generator to use.
Would either of those options meet your requirements?

[koczkatamas]

I am wrapping a third-party analyzer and I was not aware it is possible to modify these configuration values with SQALE.

Could you show me an example how does that work?

Also I wanted to open an issue because the command line arguments for the SDK are not documented (only the /a: switch) and no usage information is shown when you start the converter without arguments (or with /?, --help, etc.)

And even when I read the SQALE description while I was editing the resource file, I could not infer from it that you can use this option to re-use a modified rule file.

(I am telling you this because others can run into this or similar issues.)

So it may worth to document this feature in the README.md

[duncanp-lseg]

Thanks for the information.

Changing the SQALE file won't affect the rules.xml file - I was asking if using a similar approach to would achieve what you wanted, and it sounds like it would.

(FYI as a manual workaround, you should be able to unzip the jar file, edit the rules.xml and re-zip the jar)

[koczkatamas]

Oh I see, I was thinking about an option myself which allows you to modify the rules.xml file and then supply the new file as parameter, but it looked too complicated for me to implement.

Also thanks for the tip about manually modifying the rules.xml in the jar file, I am not familiar enough with the plugin format to know that this could've work. I think it could be a good workaround for other SDK users too, and even if we don't add new feature to the SDK now (this PR or a more complex solution proposed by you), it may worth to mention this little trick somewhere (probably README.md would be the most visible place for it).

[duncanp-lseg]

@koczkatamas I've added a /rules: option to the command line to allow the caller to supply a customised rules file as discussed above (i.e. run once to generate the template xml file; edit it; run again to build the plugin with the new file). The code is in the branch duncanp/rulesXml. Could you try it out and let me know if it works for your scenario please? Thanks.
The analyser generator checks that the customised rules XML file is valid XML but not whether it is well-formed - if the XML is not in the form expected by SonarQube then the SonarQube server will fail to start.
I'll create an issue about displaying command line help and update the readme.

[duncanp-lseg]

@koczkatamas FYI we've been doing some work on the Roslyn SDK this week to make the generated plugin compatible with SonarQube v7.0+. As part of this, we're dropping the ability to customise the SQALE.xml file (SQALE is deprecated and has been for some time), and adding the ability to customise the rules.xml file instead (see #89).
Once that ticket is implemented it should be possible to add tags and specify the rule type for each rule. I think that will enable the scenario covered by the PR but in a different way.

[Tsux]

@duncanp-sonar , wanted to have more detailed information on rules.xml. I noticed some arguments that are not covered in Readme's rules.xml sample in relation to Sonar typic rule definition, specifically 'priority' and 'status'. So wanted to know if the sample in Readme is all we have to customize the rule, or is it an expanded rules.xml that you can provide us with.
Posting this here as I noticed this PR is still open and actually attempts to add one of this missing arguments.

[pavel-mikula-sonarsource]

Hi, I'll close this one for the time being as there are some rebase conflicts. Please feel free to create a new issue and PR in case there's something to be added.