External issues are displayed in SonarQube/SonarCloud with a little badge to differentiate them from “native” issues. They count in the quality gate, but we assume the management of the rule configuration/issue exclusion will also be handled in the third-party tool. So it is not possible to enable/disable the external rules in a quality profile, nor mark an issue as false positive.
Since rule execution/configuration is out of our control, we decided to always backdate such issues, since there is no accurate way for us to know why the issue is new.
@Julien_HENRY Many thanks for the quick response. To be honest, now I’m even more confused?
"Internal issues" are for me issues detected by a SonarQube internal code analyzer. A precondition is to have a repository with rules. I create this repository with new createRepository() and add NewIssue with createIssue()/save().
On the other hand there are “generic issues” where I don’t need a repository with rules. I create a NewExternalIssue with newExternalIssue()/save(). Rule definition and issue detection is all outside of SQ.
Then we have this “external issues” (not generic issues) where I have to create a repository with createExternalRepository() and add NewIssues with createIssue()/save()?
My question is how this 3rd option is different compared to 1?
“normal” issues (what you call “internal”). Those are the issues entirely managed by SQ.
“external” issues. Issues reported by third party tools, not controlled by the SQ scanner.
External issues can be created programmatically using Sensor API newExternalIssue(). Some SonarSource analyzers also provide out of the box support of some well known issue report format for each languages. If you issue report format is not supported, and you don’t want to write a custom Java plugin, you can also convert your issue report to the Generic XML format.
External issues don’t require a rule definition. If you try to report a new external issue with a rule key that is not known by SonarQube, it will create a new empty rule definition on the fly. You can also provide rule definition during the analysis (we call that addhoc rules). Finally, you may still want to pre-register rules definitions, in order to enforce consistency/reserve the engine id/rule id.
So your options 2 and 3 are basically the same concept (external issues) but with the optional possibility to pre-register rules definition.
External issues summary:
External issue created without (external) rule definition (an empty one will be created automatically) using newExternalIssue()
External rule + External issue created during analysis (=adhoc rule). Using newAdHocRule() + newExternalIssue()
External rule defined in advance in the SQ server using createExternalRepository() then external issues created during the analysis
newExternalIssue() doesn’t allow to provide rules metadata (like description, tags, …). This is not mandatory, but if you have a way to know those details when processing the third party tool issue report, you can use newAdHocRule to provide them.