Make SonarLint use different quality profile than main scan?

Is it possible, when binding SonarLint to a specific project, to have SL use a different quality profile then the regular scans on SQ?

We have legacy code that isn’t going to get cleaned up, smell-wise, except when someone is making changes to one file. There are some new rules that seem like they’d be useful, especially in SL when people are typing in new code. However, there is resistance to turning them on because of all the “new” smells that would show up in the statistics due to the legacy code.

Is there a way to get some rules to be applied in SL but not be applied when scanning code in SQ? For instance, by having SQ scans use quality profile A, but have profile B inherit from A with some additional rules activated, and have SL use profile B while the analyzer on SQ itself uses profile A? We’d still like SL to be bound to the specific project, so that issue resolutions such as false positives are available to SL so that resolved issues and reviewed hotspots don’t show up in SL.

Of course, a downside of this is that if new code violates a rule and the coder doesn’t notice it in SL, it won’t be noticed unless someone else brings up the same file in their IDE.

The basic goal is to be able to turn on new rules and have violations of those rules appear in SL without any violations showing up in issue count statistics, particularly when caused by old code. So any combination of actions which produces this desired result is fine.

Hi @MisterPi ,

When you activate a new rule on SonarQube, the next analysis should detect that and handle it by “backdating” issues to the last commit date of the line the issue is attached to. So normally it should be pretty safe to enable new rules without messing up your leak period. Of course those issues will still appear in the overall results, but if you follow the “fix the leak” approach that we are promoting, it should not be a big deal.