New config options for issue/summary comments desactivation and previous summary deletion

[mably]

trafficstars

This PR adds five new project configuration options allowing to:

• require a minimum level of severity for issue comments (Gitlab and Azure DevOps only),
• define a maximum number of issue comments (Gitlab and Azure DevOps only),
• disable the analysis summary comment (Gitlab and Azure DevOps only),
• delete resolved issues/summary instead of resolving them (Gitlab only),
• disable the analysis pipeline status (Gitlab and Azure DevOps only).

[Michenux]

Very interesting !! any news on the merge of this PR ?

[phermsdorf]

We would also like to have this functionality, but if you look at the other closed issues it seems like this change is generally not welcome to the project.

[eirisdg]

I think this should be the most interesting feature for this plugin by far.

I'm implementing SonarQube in a developer team with non-compliant practices (too much years writing code without supervision) and when I enabled the plugin, the MR are receiving a bunch of comments that are unaffordable for our Gitlab installation. And by the other hand, our SMTP server is burning with more than 250 mails per commit...

In a new team, without vices developing... my be a good idea not bypass this. But for teams with vices...

[brian-albright]

I would love to see this feature in Github! Our developers are complaining about the annotations being added inline, making it difficult to code review. They are using their own linting tooling, so the checks are there due to a discrepancy with what Sonar suggests.

[mc1arke]

As indicated in other MRs and related issues, I'm not supportive of introducing configuration parameters that do not follow the standard Sonarqube setup as these invariable get misunderstood by users and lead to more issues being reported. If you want this feature then raise a request against sonarqube developer edition to allow filtering of reported issues and I'll then implement against the configuration and interfaces they provide.

I'd also suggest that teams should be reviewing their tooling or working practices. If you really have that many issued being reported per MR/PR then you're introducing issue blindness and will never get to a point that your code is ready for a realistic review.