Feature request: Filter Issues on Type

[fhaester]

I am working in a big project (millions of lines of code) in the public sector. We are currently using JQA+SonarQube to check some architecture constraints and we plan to extend many rules. For the time of the transition to the new rules we will have a very high number of JQA constraint violations(=issues in SonarQube). To handle such a big number of issues we need a way to filter on the types.

But currently all JQA constraint violations are displayed under the same "SonarQube Rule": "jQAssistant Constraint Violation". I could not find any way to filter on the different types of JQA constraint violations in SonarQube.

Example: It is not possible to filter on issues that are violating "constraint1":
<jqa:jqassistant-rules>
<constraint id="constraint1" severity="major"> ...</>
<constraint id="constraint2" severity="major"> ...</>
</jqa:jqassistant-rules>

• Suggestion 1: I guess any SonarQubePlugin needs to provide the list of "Rules" it is working with at load time. But the sonar-jqassistant-plugin does know the names of constraint-violations only when parsing the jqassistant-report.xml. I guess this is why every violation is considered belonging to the same Rule "jQAssistant Constraint Violation" (correct?). You might provide a way to configure constraint violation names ("constraint1", "constraint2") in a configuration that is known at load time. When parsing jqassistant-report.xml the violations can that be assigned to the corresponding rule. (...or to the generic "jQAssistant Constraint Violation", if there is no matching Rule name. This way nobody needs to provide this configuration, the plugin would still work as before).

• Suggestion 2: As a "workaround" it would also be possible to tag any issue with the name of the constraint violation while parsing jqassistant-report.xml. Than you can filter on the tag.

We are using: SonarQube Version 7.9.2 (build 30863) QJA 1.6.0 sonar-jqassistant-plugin 1.8.2

Please let us know what you think about the suggestions. Please also let us know if you have any other idea or suggestion on how to filter on the type of violation.

Thanks a lot you for your help. Best regards, Florian Haesters

[DirkMahler]

• Suggestion 1 had been implemented initially but turned out to be only hardly useable in enterprise environments - redeploying/restarting SQ instances for new/changed rules was not acceptable. The fallback to the generic constraint indeed could be an option.

• Suggestion 2 is not supported by the SQ API

But it seems that w/ SQ 7 there is support for external issues allowing dynamic creation of rules, see https://community.sonarsource.com/t/generic-issue-data-ad-hoc-rules/9624. Looking at the Java API under the hood it seems to be exactly what we need for jQA. We will investigate this.