we want to activate some 40 additional rules in the near future.
To determine whether problems with individual rules are to be expected, we have initially activated them with the severity INFO - which is not part of the quality gate.
Now the trial period is over and we want to set the severity to CRITICAL soon.
I guess this will not cause existing issues with severity INFO reappear as new issues with severity CRITICAL due to backdating.
But to be completely sure, is this correct or am I wrong?
That is correct. As long as the issues are tracked with code changes, most of their properties are kept unchanged, including the severity.
Thanks for quick response.
What if there are changes in the class | method that contains the issue with severity INFO ?
Guess it’s recomputed as CRITICAL, right ?
SonarQube attempts to “track issues” so that even if the code where the issue is located moves, the issue is matched with the existing issue in the DB, and its characteristics are kept.
If the rare cases where the matching fails, the old issue is closed and a new one is created with all the default characteristics (in which case the severity originates from the rule’s severity).
@Rebse Sorry but I was wrong.
The severity is kept unchanged only if the user manually changed the issue’s severity. The idea is that user inputs to the issue are preserved.
Otherwise, the severity is updated to match the rule’s severity.
You’ll see an entry about that update in the issue’s activity tab:
The behaviour is not consistent.
Testing (Sonarqube 9.9 LTS) for a legacy project, means quality gate has only conditions on new code.
Quality gate has major/blocker/critical issues > 0
First scan => quality gate passed.
Second scan with rule activated, severity INFO => 4 issues for this rule, quality gate passed
Third scan with rule severity changed to CRITICAL => 2 new critical issues, quality gate failed.
2 issues ↔ 4 issues ?!
Do the other 2 issues still exist with severity set to INFO?
I’m assuming no changes were done to the severity in the UI?
One last thing: I see that the 2 critical new issues have a creation date of over 1 year ago. How are they part of the new code period?
Sorry, my bad. Used the wrong branch for the test above and the project new code setting has the (empty) main branch as new code reference, means the whole branch is treated as new code.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.