Skip to content
This repository has been archived by the owner on Apr 27, 2021. It is now read-only.

Configure RuleType mapping for external rules #859

Open
mum-viadee opened this issue Jun 18, 2019 · 2 comments
Open

Configure RuleType mapping for external rules #859

mum-viadee opened this issue Jun 18, 2019 · 2 comments

Comments

@mum-viadee
Copy link

I want to request a feature.

Hi, in our project we import tslint issue reports (see #619) in our CI pipeline. All external issues (eg. from tslint-microsoft-contrib) are imported as RuleType.CODE_SMELL. It would be nice, if there could be a possibility to configure a mapping between Rule and Type for external rules.

@vilchik-elena
Copy link
Contributor

@mum-viadee thanks for the request. We will think about it.
Do you already see any way for us to do it? There is ruleSeverity property available for each issue (error or warning). But I'm not sure how it can be used for rule type.

@mum-viadee
Copy link
Author

mum-viadee commented Jun 21, 2019

Hi @vilchik-elena ,
thanks for your quick response. I thought of how one could configure the needed mapping for the external issues and came to two solutions:

  1. Create a configuration view in SonarQube to configure SonarTS and add external rules with name, type and default severity.

  2. Add the possibility to place an optional configuration file (e.q. sonarts.json) in the workspace where the mapping between external rule name, rule type and default severity can be configured.

Both solutions would work identically only the way and place the mapping is configured is different. The configured mapping should be used by SonarTS to import external rule issues. The rule name would be the key to look up the type and default severity in the configuration.

The hard-coded mapping, as it is today could be the fallback if no configuration is found for an imported external issue.

I know that the rule names are not unique, so there could be collisions between external ans build-in rules. If so, the build-in mappings for SonarTS rules should have higher priority than the configured ones. If one rule name is configured more than once, the first occurrence of the rule mapping should be used.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants