Hi all!
Today’s my chance to send out this week’s roundup with @andres taking a much deserved break.
This week we’re excited to share that, hot on the heels of Gitar joining Sonar, the beta for Gitar on Azure DevOps and Bitbucket Cloud is opening up. If you use either platform and want early access to Gitar’s AI code review, you can sign up here. Gitar doesn’t just leave comments in your PRs, it delivers real fixes, validated against your CI pipeline, so your PRs are production-ready faster. We’d love your feedback as we roll this out!
So now, like every week, we’d like to 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
The SonarQube for Eclipse plugin was spawning thousands of parallel jobs for every IssueChanged event in large workspaces, overwhelming the Eclipse job scheduler. @fedejeanne went above and beyond by proposing a concrete singleton fix and providing detailed reproduction logs, confirming the root cause. A fix to batch the updates into a single workspace operation is now in progress.
A 120-second EDT freeze was occurring during pre-commit in PyCharm 2026.1.3 with SonarQube for IDE 12.4.0, caused by module lookup blocking the UI thread for each committed file. A fix has now shipped, so update to the latest version if you’re still seeing this. Thanks @jguillot.lynxview for the report!
SonarQube Cloud
PR analysis cache hit rates were reporting near-zero when the PR checkout directory differed from the main branch, an issue that @Adam_Birem identified back in January with a careful experiment, confirmed by @gtoison and @Thomas_Zoratto1. A fix has been implemented and will land on SonarQube Cloud soon. Thanks for staying the course, @Adam_Birem!
@stefansta noticed that beta-tagged PowerShell rules had appeared in the Sonar way Standard profile on SonarQube Cloud and asked why. After internal discussion, we’ve decided to remove the beta label from rules entirely, so stay tuned for the announcement!
@Oodini flagged that when a GitLab-granted token expires during analysis, the error message is identical to the one shown when a SonarQube-generated token expires, making the root cause nearly impossible to diagnose. You’re right that these deserve distinct messages, and we’re tracking the fix in SONAR-30831.
SonarQube Server / Community Build
The documentation was missing guidance on upgrading a database to a newer version from the same vendor while keeping the same SonarQube Server. @MisterPi raised this gap, and we’ll be updating the docs to clarify the same-vendor DB migration procedure.
@michha caught a discrepancy in the documentation for sonar.issues.sandbox.default, where the Common Properties page was describing the property type incorrectly. The docs have been corrected. Nice catch!
Rules & Languages
php:S1448 was raising a false positive on classes annotated with @Entity via PHPDoc comments, as the rule’s exception was only checking PHP attributes, not PHPDoc annotations. @cesarfreire reported this and a fix will roll out with upcoming releases. Thanks for reporting!
@onigoetz spotted a false positive from php:S1172 (“Unused function parameters should be removed”) on PHP 8.1+ constructor parameters promoted with only the readonly keyword and no explicit visibility modifier. The fix will roll out in an upcoming release. Thanks for the clean SonarCloud reproducer!
SonarQube CFamily failed to analyze a legacy TI C2000 project because the older cl2000 6.4.9 toolchain doesn’t report \__SIZEOF\_\* macros during probing, causing the analyzer to default to x86_64. @thais_csc provided debug logs and a full reproducer that confirmed the root cause, and a fix to recognize the TI C2000 toolchain is now in the works, with --define as a workaround in the meantime. Thanks for the thorough investigation!
@LoicDavid raised a false positive with typescript:S7773 (“Prefer Number.NaN over NaN”): the rule was flagging NaN assignments inside constants, even though defining a named constant for the value is perfectly valid. You’re right, and JS-2012 is now tracking the fix.
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!
Stevan