Generic issue data & ad-hoc rules

(Ruud Senden) #1

Recent SonarQube versions provide support for importing external/generic issue data as described here: https://docs.sonarqube.org/latest/analysis/generic-issue/

One of the fields in the described issue JSON data is the ruleId, however the documentation doesn’t specify how the external rules referenced by this issue ruleId field can be imported into SonarQube. For example, how would you add an appropriate rule description for these external rules?

For comparison, in a SonarQube plugin you could use SensorContext.newAdHocRule() to define an ad-hoc rule, and add a rule description using NewAdHocRule.description(). You can then use SensorContext.newExternalIssue() to generate external issues for these ad-hoc rules.

Is a similar approach solely based on the generic issue JSON data possible, without requiring a custom SonarQube plugin?

(G Ann Campbell) #2

Hi,

The ruleId is expected to be the external analyzer’s id for the rule. There’s no requirement to feed rules ahead of time, and no there’s no need for a custom plugin.

 
HTH,
Ann

(Felipe Zorzo) #3

@ganncamp I think I have the same question. If we import some generic issue data, we can’t show the rule description in the SonarQube UI:

image

To see the rule description, we need to copy manually the rule id and check the description in other tool. It’s OK but not perfect, will you improve it in the future?

(Ruud Senden) #4

Correct; it seems like in the JSON-based external issue data import you can only provide a rule id, no rule description.

In comparison, a SonarQube plugin can generate ad-hoc (external) rules and provide descriptions for those ad-hoc/external rules, so why is this functionality not available (or not documented) through the JSON-based import?

Another related issue that I ran into; if SonarQube cannot find the corresponding source file for an external issue (or if no source file is defined in the external issue data), the issue will simply be ignored. I think it would be much better to report these issues at project-level instead of just ignoring them.

Likewise, a SonarQube plugin can only report external issues against InputFile components; a plugin is not allowed to report external issues at project level.

I know SonarQube is meant as a static analysis tool, and not as a generic dashboard for all project-related issues. Nonetheless, many people want to use SonarQube as a generic dashboard, and for example want to have visibility of DAST issues (which are not related to any specific source file) in SonarQube.