Hello Sonar Community!
It’s been a big week here in the Community, with lots of help and guidance from you, our members, to improve our products and your experience with them.
We’re grateful when you take the time to do that, so like every week we want to spend some time acknowledging everyone who prompted interesting discussions and gave us feedback to help us continuously improve.
SonarQube:
- SonarQube incorrectly aggregates SimpleCov Ruby coverage reports, which is a thorn in of @GreyTeardrop who has gone to great lengths to diagnose this issue and even issue a pull request. Hope we see it merged soon! SONARSLANG-653
SonarCloud:
-
Thanks, @LeviateK for your report that the Azure DevOps Summary Report isn’t legible in dark mode. We’ve created an internal ticket to improve that.
-
The manual analysis tutorial implies that you can use the
SONAR_TOKEN
environment variable for authentication with the Scanner for .NET, which isn’t the case (yet). We will fix the tutorial. Thanks @Shaine_Gordon! -
Have you ever exceeded your license limit and not known where to look for what files are causing the overage? @NachoEspiral ran into that, and after some discussion, we created a ticket to give more information to the user when that happens. Thanks!
-
@PeterBa hit a
duplicate key
error for one of his projects. That led us to uncover a race condition in DB data insertion which we’ve created an internal ticket to fix. -
@aurelienlupin wasn’t happy with needing to use a personal access token to set up his GitLab integration and discovered that a group access token with the reporter role and API scope will work. Thanks! We’re updating the docs.
-
Thanks @Adrie for pointing out a typo in the SonarCloud docs. It’s already been fixed thanks to your report!
SonarLint:
-
Users of SonarLint for Eclipse might find it uses more disk space than expected (and keeps on growing). Thanks @Ricetrac and @hok for the reports. SLCORE-858
-
Some IntelliJ users are seeing a
No log output configured
error that they shouldn’t. SLI-1449 will be handled soon to kill the noise. Thanks for the reports @SnehasishChar and @KevinArnaudLille!
Rule & Language Improvements:
-
javascript:S6582
should be able to detect thatarray && array.length > 0
is better shortened toarray?.length > 0
, and other similar issues. Thanks for the report @Udo_Pape-Kampmeier! JS-184 -
Our Typescript analysis relies on type-checking, but currently doesn’t support yarn PnP module resolution. This leads to false positives.itives. We’ll consider adding support with JS-181. Thanks @mon0051!
-
plsql:FunctionLastStatementReturnCheck
raises a false-positive whenCASE
statements are used. Thanks for telling us @Peter0! SONARPLSQL-843 -
We know that some of our C++ rules report “valid” issues on function signatures, but it’s not possible to act on them, because the developer has no control over the signature. We’ve got that on our ToDo list already, and @mkhachayants helped us find another case where it’s relevant:
cpp:S4998
. CPP-5365 -
@TimBijnen’s reproducer actually showed us two false positives for the price of one! We’ll be fixing both
csharp:S2589
andcsharp:S4158
as a result: sonar-dotnet#9425 -
It turns out that
java:S2259
is blind to NPEs in the context of Log4j2. Doh! Thanks @nicolaomnius. SONARJAVA-5030 -
scala:S126
only raises an issue on a missingelse
clause if there has been a precedingelse if
. But @Valter_Fernandes pointed out that in Scala, not having anelse
is always considered a bad idea. Great point! SONARSLANG-652 -
We’re going to update
javascript:S2699
to support more assertion libraries, after reports from @Alain_Dubrulle and @gian1200. Thanks! JS-187 -
java:S118
shouldn’t recommend a private constructor for utility classes defined inside methods. Thanks @Nicolas71! SONARJAVA-5027
Once more, we extend our thanks to everyone mentioned here - and those we may have missed - for their efforts in strengthening this community and enhancing our Sonar products.
Please leave your own recognitions below – whether for another community member or a SonarSourcer who assisted you this week. If there’s someone you think should be acknowledged in next week’s roundup, don’t hesitate to let us know.
@Colin, @ganncamp, and @leith.darawsheh