Hey all,
Another productive week in the community with excellent contributions from our users! As always, we want to take a moment to recognize everyone who sparked interesting discussions and gave us valuable feedback to drive continuous improvement.
SonarQube Cloud:
-
@Gr33n discovered that the “Update Path” button for renaming GitHub organizations was failing with a HTTP 400. A PR to fix this has already been merged and the fix should be live soon. Thanks!
-
@PLJAKRZ4 and @kubickim reported a severe degradation in scanner performance when analyzing C# code. We were able to quickly link this regression back to a seemingly unrelated change in our scanner engine, and the team quickly identified and deployed a fix. Thanks for the detailed reports that helped us diagnose and resolve this quickly!
-
@RobertoCircit asked whether regular analysis of the target branch is required to correctly detect which issues are “new” in Pull Requests. The answer, for SonarQube Cloud, is yes. We will update the docs to make this more clear. Thanks!
SonarQube for IDE:
- @blood0cean encountered an
java.lang.IllegalStateExceptionwhen using SonarQube for IDE with WebStorm. We’ve created a ticket SLI-2090 to address this. Thanks for the report!
SonarQube Server & SonarQube Community Build:
- That same issue from before with performance degradation in SonarQube Cloud? @kushlychok and @github-antonc faced it on SonarQube Server. We intend to backport this issue. SONAR-25269
- @Sam_Kemp and @random-devops encountered an issue after upgrading to SonarQube 2025.1 LTA where all analysis tasks were failing with
Cannot invoke "org.sonar.db.qualityprofile.QProfileDto.getKee()". This appears to be related to quality profiles not being properly marked as “Default” during the migration process, even when they’re the only profile for their respective languages. Our team is actively investigating this upgrade issue and created SONAR-25293 to improve NPE handling. As a workaround, users can manually set quality profiles as “Default” in the Quality Profiles UI. Thanks for the reports!
Scanners:
- Several users (@Shirwa_Hersi, @diablo_robert, @robross0606, @markluebbehuesen) reported Node.js version 18 compatibility warnings when using the
sonarsource/sonar-scanner-cliDocker image. Two things are wrong here – the docker image ships with NodeJS 18 instead of a newer version, and the docker image isn’t compatible with the NodeJS binaries embedded in the Javascript/Typescript analyzer. We’ll fix the first problem with SCANDOCKER-60 while working on the second one.
Rule & Language Improvements:
-
@furti provided excellent feedback on
java:S6437’s Spring Boot property coverage for secret detection. We’ve added additional Spring Boot properties to the detection rules and created SONARIAC-2064 for further improvements. Great suggestions! -
@a10r and @Corniel reported a false positive with
csharpsquid:S4158when modifying collections through aliases. The rule incorrectly flagged code where a collection was being modified via a reference variable, even though the collection wasn’t actually empty. Our team confirmed this as a false positive and added a ticket to the backlog for a future fix! Thanks!
Community Contributions:
- Special recognition goes to @rolnico who shared an incredibly detailed solution for configuring secured GitHub workflows to launch Sonar analysis for PRs from forks. This is exactly the kind of in-depth knowledge sharing that makes our community stronger!
Thank you again to everyone mentioned—and to those we may have missed—for your ongoing contributions in making this community stronger and helping us improve Sonar products.
If you’d like to give a shout-out to someone, whether a community member or a SonarSourcer who helped you, please do so below. And if there’s someone you think we should acknowledge next week, let us know!