How to configure rule severity

[daniell0gda]

Hey, Thanks for your great work.

It seems that there is no way of configuring rule severity, I am wrong?

SonarQube is showing rules for typescript and many of them are considered "major" "bug" type (some of them are "smells" but still "major"). I cannot find a way how I could do it. I've tried using severity, like so (tslint.json):

        "indent": {
            "options": [
                true,
                "spaces"
            ],
            "severity": "warning"
        },

And this doesn't work.

So, to sum up, could some one tell me how to :

• set different issue types
• set different issue weight/severity

Thanks!!

[Pablissimo]

You override those settings in the SonarQube admin interface itself - the plugin puts some best-guess defaults in (if you disagree with those then I'd be interested to hear your views, it was a fairly arbitrary decision by me so far).

Hit the Rules tab in your admin interface, pick the rule you want to change and then the Change button to alter the severity. You will probably need to re-run analysis to get the altered rule setup to be recognised by any project.

I'm not sure that you can change the Bug vs Smell vs Vulnerability through the admin interface, it's not something that's even been a requirement for me.

[daniell0gda]

Thanks for your reply. For me it is a bit fuzzy what rules are overtaken by what. In context of c# rules we have every configuration and rules sheet in different files - which are then configured to be used in sonarqube. Thanks to that If something happens - settings in sonarqube are safe.

And configuring typescript, one thing was surprising for me. I saw rule list in sonarqube and in order to disable rule I could edit my tslint.json but I Imagine I can also disable rule in sonarqube right? So surprising part was: what has priority. And now when I think of it - why do I even need tslint.json if all rules are already there (sonarqube) and I can only enable/disable rule in tslint.json. I guess for configuring exact rule right?

It would be just awesome if this would be 1-1 (in favor of file configuration) because now I can see bunch of rules (all are kinda enabled - but I know that they aren't) and I am not sure if I should spend my effort into configuring it in sonarqube to be one day surprised that someone accidentally reverted it and I cannot go back :)

As far for severity, in most cases I do agree with it, but I don't think "space-related-rules" should be major because in the end code will be just harder to read :)

[Pablissimo]

It's different to the C# setup because the C# scanner is the thing actually doing the analysis, whereas for the TypeScript scanner it offloads that to the tslint tooling. That means you're configuring things in two places, which is awkward but you can make it easier.

I tend to just enable all the TypeScript rules in SonarQube, and then control which ones I actually want reported on by enabling or disabling them in tslint.json. That way you're really only configuring things in one place, and your local runs of tslint will match SonarQube's reporting all the time.

There's no real priority between the rules defined on both ends, it's a collaboration - disabling a rule in SonarQube won't stop tslint reporting the issue back to the plugin, we just won't record the breach. Similarly enabling a rule in tslint won't report it in SonarQube unless you've also enabled the rule.

Which space-based rules are major that are tripping you up? I'd thought purely-stylistic ones I'd allocated as minor so that might be a bug.

[daniell0gda]

Ok, I think I can live with it although I think severity should be configured by tslint.json. It is actually possible in it's schema.

It seems that rules are set to different severity: But I've got tons majors of:

• Consecutive blank lines are forbidden
• missing whitespace
• statements are not aligned
• parameters are not aligned
• misplaced opening brace
• expected nospace before colon in call-signature Maybe more but I have only few rules now turned on..

[Pablissimo]

Ah ok, I'll take a look at those - some of them are to keep it in sync with the Javascript plugin (since the same concerns broadly apply) but I'm surprised at a couple being down as major.

The trouble with severity in the tslint.json file is two-fold:

• Rules have a default severity defined by the plugin at start-up time - not at analysis time, so I won't have an example tslint.json file to pull severities from (this may be workaroundable if the project had its own quality profile, I'm not sure, but I think the plugin would have to create it on your behalf)
• If there were two projects analysed with different severities listed in their config file, which should the plugin choose? I'm using the plugin on an instance with 40+ projects operated by different teams in a largeish business, all of whom will have different requirements for their quality gates
• The tslint.json severity support didn't exist back when the plugin was created, and one of the more recent goals of the plugin is to try to avoid knowing too much about how tslint gets configured and just trust its output

I might have a look at custom profiles being created by the plugin, though to be honest I'd be surprised if it's a supported feature of SonarQube.