Sonar Community Highlights, November 11 - 17

[Colin]

Hey everyone!

It’s been another busy week in the Sonar Community! Like every week we want to spend some time saying thanks to everyone who prompted interesting discussions and gave us feedback on Sonar products that will help us continuously improve.

SonarQube:

• @bdellegrazie raised an interesting point about the Helm chart install process for SonarQube, inquiring about the possibility of using a ConfigMap instead of a Secret for caCerts. We’ll add this possibility with SONAR-21053! Thanks!

• A big shoutout to @jenspopp for raising a question about rule key validation in SonarQube. A bug ticket has been created to align things between the API and rule templates. SONAR-21052

• Hats off to @awsmman for reporting an integration issue with SonarQube in an Android project. This is related to a known issue (and there is a workaround reported in the thread). A permanent fix will come with SONARJAVA-4697.

• There was an update (just today) to the Azure DevOps extension for SonarQube that caused some issues reported by @bper19 and @GamIstAr. Thanks for the reports – we’ve issued some patch releases already.

• Thanks to @Tsuesun for seeking clarification on the use of SONAR_WEB_JAVAOPTS versus SONAR_WEB_JVM_OPTS in SonarQube’s Helm chart. This query highlighted confusion in the documentation regarding deprecated environment variables. We are going to update the documentation.

SonarLint:

• Kudos to @anon67236913 for bringing up a NodeCommandException issue when using SonarLint and the embedded NodeJS runtime. In some environments, it’s necessary to use another NodeJS runtime, and we’ve created SonarSource/SonarJS #4400 to handle that.

• Props to @Cyril_Dragomyr for reporting an IndexOutOfBoundsException in SonarLint for IntelliJ. We’ll fix this with SLI-1174

• Props to @Dubble_Majax for raising a concern about the handling of SonarQube exclusions versus SonarLint behavior in IntelliJ. SLI-1176 has been created to work on clarifying exclusion settings.

• @sirojnurulum is getting an error when using SonarLint for GoLand that we will fix with SLI-1177. Thanks for the report!

• Many users, including @Bobsans, @kpervin, @ifeanyichukwuOtiwa-s and @Nicolas_Roquebert reported an issue with SonarLint where an error message of Timer already cancelled is being thrown. We’ll fix this in the next version. SLI-1175
  

Rule Improvements:

• Big thanks to @Jos_Abrahams for highlighting a false positive with rule cobol:S1461
  (Unused sections should be removed). This issue, where sections used in a SCREEN SECTION were not recognized by the scanner, is being tracked at SONARCOBOL-1689.

• Shoutout to @kurteous who reported a false positive issue with kotlin:S100 when using Jetpack Compose (highlighting a contradiction with the Compose style guide). SONARKT-374 will fix this up.

• @corniel suggested that csharp:S3925 not be raised on code targeting .NET 8. Great catch! SonarSource/sonar-dotnet #8377

• Kudos to @mfroehlich for identifying a false positive with java:S3276 in dynamic generic type scenarios. SONARJAVA-4701

• Props to @msedi for identifying a discrepancy with csharp:S2930. They observed that IDisposable objects created by static factory methods weren’t being flagged as they should. This is a false-negative we’ll fix with SonarSource/sonar-dotnet #8365.

• Kudos to @kbatten raising an important issue about security hotspots in Azure Bicep modules. Keiran explained how the existing keyword in Bicep is causing false positives. We’ll work on this with SONARIAC-1143.

• Hats off to @bduderstadt for reporting a false positive with java:S3516 which was incorrectly flagging methods with Lombok’s @Slf4j annotation. SONARJAVA-4699

• A big shoutout to @hellminister for highlighting an issue with java:S1911 with the field name ‘sun’ being incorrectly flagged as a Sun class. This is a false-positive we’ll work on with SONARJAVA-4698.

• Kudos to @fidgi for initiating a discussion on enforcing the awaiting return of async functions in try-catch blocks in SonarQube. We’ll create a new rule with SonarSource/SonarJS #4370.

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, Ann and Leith