versions: custom profile sonar java rule(s) changes from 7.9.5 to 8.9
issue observed: These questions arose from the upgrade that was done from 7.9.5 to 8.9 LTS,
Looks like the custom profile(s) got updated (screenshots) during upgrade when sonar documentation “states that after copying a profile, your new profile won’t inherit any changes made to the original profile.”
After upgrade from 7.9.5 to 8.9 LTS - I notice that the metrics have changed even without running a scan of my project with a custom profile (screenshot attached) - Why ? this will happen only when new rules are applied right ?
In the excel screen shots - the rule S4424 has been removed in 8.9 (why and how can I find the reason for other rule changes in the screen shots too ?)
How are the future LTS releases planned for people who want to want on only LTS upgrades.
Why is my coverage showing 0% in the 8.9 LTS
Appreciate some answers that can help me put together an explanation.
First, thanks for the screenshots! They’re very helpful!
I know they’re all related to the upgrade, but there are a lot of questions here. I’ll try to hit them all, but if there are followups, I reserve the right to invoke “one topic per thread” & ask you to open additional threads.
There are multiple things going on here. First, it’s useful to clarify exactly what a “Quality Profile” is. It’s a sub-set of rules and severities and (optionally) extended descriptions. Some of the properties marked as changing in your screenshots are properties of the rules, not of the Quality Profile. When we say your custom profiles won’t inherit changes made to the original, we’re talking about the addition/removal of rules in the subset. Now to the specific points picked out in your spreadsheets:
Severity - IMO you’ve got us dead to rights on this one. Even though the default rule severity changed (which is a rule property), I wouldn’t have expected it to change in your profile. My guess is that if you had overridden the default severity in your profile, you would have kept that severity. Instead you activated the rule at the default severity, and so when the default changed you “kept” the default (which changed out from under you). Explicitly: we overlooked this use case & I’ll bring it up internally.
Type - While it is possible to override the default severity in a profile, it’s not possible to override the rule type. This is a property of the rule, not the profile. We re-evaluate rules on a regular basis and sometimes change type, default severity &etc. When we change rule type, you’re going to get that change in all your profiles. Existing issues raised by that rule won’t be updated, but the rule is.
Tags - Updating default tags is also part of are regular re-evaluation, and like type it is also a rule property. As such, you’ll see these changes automatically. You should not see changes to tags you’ve added yourself.
Deprecated/dropped rules - As part of the periodic re-evaluation of rules we do occasionally realize that some rules no longer make sense. In that case, we first deprecate and then eventually drop them.
Your first screenshot indicates that you have re-run analysis. The ‘before’ shows an analysis date of 21 July, and your ‘after’ shows “10 hours ago”. I’m not sure why Duplications would have dropped, but my guess is that the issue-related value changes are generally related to rules getting smarter.
Regarding S4424, that’s a darn good question. I’m going to ask internally. (Hopefully the rest of this question was answered by #1.
I don’t understand the question. LTS releases are already planned for people who only want LTS upgrades.
At a guess, you were using the JaCoCo .exec format for coverage reporting. That’s no longer supported. You’ll need to switch to the .xml format. You may find the LTS to LTS upgrade notes helpful.
S4830 was added as a 1-to-1, new & improved replacement of S4424
All existing open issues initially raised by S4424 were (should have been) moved seamlessly to S4830
The process and ticketing used at the time for the replacement were kinda flaky
We’ve since improved our processes so this shouldn’t happen again.
With a little prompting, the ticket(s) involved were retroactively updated to make what happened clear. And so in the end, this is the ticket you’re interested in:
SONARJAVA-3201 - Rule S4830: Server certificates should be verified during SSL/TLS connections
Ann,
I really appreciate the detailed response to each one of my question, Have a much clearer understanding now
As per documentation it says “Tags are a way to categorize rules and issues”.
Will moving around Tags (out of the box) in a rule (“sysTag added/removed” - spreadsheet screenshot) - will this impact the metrics too ?
