There are 2 different use cases which are currently badly covered or not covered at all by SonarQube and SonarCloud:
- Some rule engines or pack of rules are well tuned to target a known development framework. As an example, Android Lint, ESLint pack for AngularJS, TSLint pack for React, Microsoft.NetCore.Analyzers Analyzers for APIs specific to .NET Core, etc. There is no way for SonarQube/SonarCloud users to benefit from the value of those rule packs, and we can't really expect SonarSource to deliver one day similar rules.
Moreover, when our users rely on such external rule engines, most of the time the configuration of this rule engine is managed through a configuration file that is part of the source code. This represents the rule set and settings to be used by the external rule engine when running an analysis. If we provide a way to feed SonarQube/SonarCloud with issues coming from those external rule engines, our users expect to still rely on their own configuration files to define the rule set and settings to be used.
At the same time:
- We believe in the value we generate through our own code analyzers: behaviors finely tuned to generate few FP, valuable rules based on pattern matching techniques or a symbolic execution engine, only relevant rules activated by default in Sonar Way, consistency across code analyzers, ability to cover all languages without having to install third party tools for each language, documentation, ...
- We believe in the concepts of Quality Profiles and Quality Gates.
So the challenge becomes: is there a way to benefit from the existing SonarSource's code analyzers and from all the related concepts of Quality Profiles and Quality Gates while still being friendly with external rule engines by providing the ability to inject issues from them?
The new main idea and game changer when dealing with external rule engines is to not try to configure them from SonarQube/SonarCloud. The only rules that should be available in the Rules and Quality Profiles pages should be the rules provided by the SonarSource's code analyzers.
The second important idea is to not consider the SonarSource's code analyzers and the external rule engines as being in competition but as being complementary. Even if obviously it should be possible to rely only on the SonarSource's code analyzers without feeling the need to use any other external rule engines. Moreover in case of functional overlaps between the rule engines, we should provide a way to smartly manage (see below) the "duplicated" issues.
And finally, it should be possible to dynamically import some external issues without having to have previously (via plugin loaded at startup) defined/described in SonarQube/SonarCloud those external rule engines, the types of issues (bug, code smell, vulnerability), the remediation function of each external issue, ...
- No way to add external rules to a Quality Profile, and therefore no impact on the content of the Rules and Quality Profiles pages.
- There must be a visual way to dissociate external issues from the other ones.
- In the Issues page, imported issues should be grouped by "rule title" as any other issues with help of the "Rules" facet
- A new SonarQube API allows callers to programmatically inject external issues from a code analyzer. This API allows any code analyzer to directly support the standard format of an external code analyzer like CheckStyle, eslint, android lint, ... If any required value is missing or invalid (e.g. Severity=dropEverything) analysis will fail. For each external issue we expect to have:
- source file
- type (bug, code smell, vulnerability)
- For each issue we will also accept these optional data points:
- precise issue location
- 2ndary locations, optionally with message and extra file (
- remediation cost - defaults to 0
- The new API will be fronted by a Generic Issue Data format, analogous to the Generic Test Data format
- the analysis parameter fed by these reports must accept multiple values so that the user is not limited to choosing a single external analyzer
- There should not be any way in SonarQube/SonarCloud to switch off external issues either via exclusions or by flagging them as Won't Fix/False Positive. Indeed, the same way the external rules are not managed in SonarQube/SonarCloud, the external issues should not be switched off in SonarQube/SonarCloud.
Issues raised by external analyzers will be marked by a badge naming the analyzer. This badge has to be small yet visually contrasting to not be missed.
The same badge will be displayed inside the rule panel. The link to the specific rule will lead to an external page. Hence the "external link" icon replacing our classic "link" icon.
Rules will appear in the "Rules" facet of the Issues page.