Hello Community!
This week, a new version of SonarQube CLI was announced, packing an array of new features. If you are working with AI agents and you are interested in integrating your agentic workflows with your SonarQube solution, then you should SonarQube CLI out!
Let’s now take a moment to recognize you, the users, who help improve the ecosystem for everyone by sparking valuable discussions and providing feedback to drive continuous improvement in our products.
SonarQube for IDE
@Tom_Luo spotted that SonarQube for IDE in Rider was showing duplicate issues in the Problems view, reproducible across multiple issue types including HTML/cshtml. A fix is on its way in the next release. Nice catch!
SonarQube Cloud
@akumbhar flagged a confusing “Error fetching component measures” log that appears when publishing quality gate results from Azure Pipelines using a Scoped Organization Token. You’re right, it’s misleading! We’ll downgrade this to a DEBUG-level log and plan to extend Browse permission to SOT.
An intermittent HTTP 403 incident hit GitHub Actions users downloading scanner binaries or querying the JRE metadata API. @lprada (1) and @daniel-gray (1) had flagged related pre-processing failures as far back as April. @Elijah_Taylor-Kuni (2), @timsavage (2), @divya_nayaka (2), @krishna_chalise1 (2), @AaronC81 (2), and @Jacob-Lowey_octa (2) all reported the June incident. After we fixed binaries.sonarsource.com, @mortenmorten (2) spotted that scanner.sonarcloud.io was also affected. The incident is now mitigated, thanks for reporting this, everyone!
The severity filter in Portfolio custom dashboard widgets turned out to be a bug, as @Mrigakshi helpfully caught: selecting “High” was including Blocker and other higher severities rather than filtering to that exact level. A fix is in the works.
SonarQube Server / Community Build
@Scott flagged that building SonarQube from source had broken again due to missing scanner-engine dependencies that weren’t published to Maven Central. @Josue_A_de_Lima later reported it was still broken with additional missing .NET plugin artifacts, which took a few rounds of fixes to fully resolve. The latest version now builds cleanly, and thanks to both @Scott and @Josue_A_de_Lima for staying on it!
@mstockhammer reported that SCA scans were crashing in SonarQube Server 2026.3.0 for projects containing legacy UUIDs. The fix shipped promptly in 2026.3.1, and @mstockhammer confirmed it’s working again. Thanks for closing the loop!
An open-source npm package for calling the SonarQube API from Node.js or TypeScript maintained by @titan just got fresh updates. It’s great to see that our users are working on such Sonar-related projects. If you’re building automation, dashboards, or reporting tools, check out sonarqube-api-client!
@sonar-qube-user sparked a thorough discussion about sonarqube-agent-plugins and build-less C/C++ analysis on SonarQube Server. The discussion touched on what these plugins are and what they are not, and on what can be accomplished with different modes of C/C++ analysis. Insightful!
Scanners
SonarScanner for .NET crashed in Azure DevOps pipelines for @Cory_Crooks with “Cannot register highlighting rule for characters at Range,” caused by overlapping highlight annotations in .razor files. A workaround is available: pass /d:sonar.cs.analyzeRazorCode=false in the begin step while a fix is in progress. Many thanks for the report, @Cory_Crooks!
@bc-lee reported that SonarScanner for Gradle 7.3.0 was providing invalid sonar.java.binaries for AGP 9.2 projects, and went above and beyond by opening a PR to fix it. @vakdeniz also confirmed the issue, while @rvp-diconium separately caught that licensee { bundleAndroidAsset = true } was crashing the sonarResolver task. Thanks also to @Gustavo_Morales, who had worked out the root cause in detail earlier. All fixed in SonarScanner for Gradle 7.3.1, and we owe it all to you!
Rules & Languages
java:S6204 raises a false positive when the collected list is later modified through Iterator.remove() rather than removeIf(), as @Emilyaxe caught with a clear reproducer. The ticket SONARJAVA-5349 tracks the fix.
@igarshep reported what looked like a false positive on yield in a nested switch expression. It’s actually a true positive, but the rule message doesn’t make clear how to simplify the code; we’ll improve the description and add a quick-fix: SONARJAVA-6398
kotlin:S6508 fires a false positive on Mono<Void> return types in Project Reactor code, as @Laurent_T_Locala pointed out. We acknowledge the issue and will work on a fix, thanks for the catch!
Thanks again to everyone mentioned here - and to anyone 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!
Andres