Hello Community!
This week we have two new Gitar resources worth bookmarking. First, a new video walks through how Gitar and SonarQube work together, showing how AI-suggested fixes flow into your existing code review workflow. Second, a new course goes further, covering how to automate the full journey from suggested fix all the way to auto-merge. If you’ve been curious about Gitar but haven’t had a chance to dig in, these are a great place to start.
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 Cloud
A persistent “GitHub auto-import errors detected” banner that no amount of reinstalls or provisioning toggles could clear brought @Alaa-Eltizam to the community: when an auto-import fails and the repository is later deleted from GitHub, the failed-import record has no way to self-clear. We’ve confirmed this is a known limitation and are tracking a fix internally.
SonarQube Server / Community Build
@supervos noticed that the new Architecture analysis feature fails to load configuration for projects created before SonarQube adopted UUID-format project IDs, producing a “Failed parsing as UUID” warning. A fix is on the way and will roll out with upcoming releases.
Scanners
@Harshit_Pandey provided a beautifully thorough report showing that SonarScanner for Gradle 7.3.1 double-registers Android-specific source sets for Kotlin Multiplatform modules, aborting analysis with a “can’t be indexed twice” error, and the fix is tracked in SCANGRADLE-429. @Daniel_Dello went above and beyond by contributing a detailed workaround script directly in the thread while the fix lands. Thanks to you both!
Collecting C# test coverage in Cobertura XML format and attaching it to a TRX file surfaced a bug that @carlossus noticed: SonarScanner for .NET incorrectly attempts to convert the already-XML report as a binary .coverage file and logs a spurious error. Coverage still uploads correctly, but the misleading message is confirmed as a bug and is in our backlog to fix.
@carlossus also asked whether SonarQube supports Cobertura XML for C#, and the answer is yes: it’s been supported since SonarQube Server 2026.3 via sonar.cs.cobertura.reportsPaths, tracked in SONAR-27673. The feature had slipped out of the main .NET coverage docs, and we’re working to correct that!
Rules & Languages
A rule proposal from 2024 has borne fruit: @reitzmichnicht suggested that Spring @Transactional methods should flag when rollback behavior for checked exceptions is left unspecified, and java:S8989 has now shipped on SonarQube Cloud and will roll out with upcoming releases. A huge thank-you to @reitzmichnicht for the patience and persistence. It clearly mattered!
@FORIMOC put together a careful, CVE-backed proposal for a new Java path traversal rule covering archive-derived paths, request-parameter paths, and template resource lookups via ClassLoader.getResource. The first two shapes are already handled by java:S6096 and java:S2083, and we’ll be extending both rules to add ClassLoader.getResource as a sink.
java:S2119 raises a false positive on a Random object that’s statically initialized in a method chain, and @fbauzac let us know. You’re right, and it’s already fixed in the latest release!
Many thanks to @Oodini for reporting a misleading “Project not found” error that turned out to be an expired GitLab token rather than a missing project. SONAR-30831 was created to improve error messaging in this case.
@Chordrain and @MarkLee131 let us know that java:S3063 silently misses StringBuilder and StringBuffer instances when the declaration and assignment are split into two separate statements. SONARJAVA-6694 has been opened to fix this gap.
@Jeroen_van_B spotted that java:S8786 flags simple anchored patterns like \d+$ when used with Matcher.find(), because partial matching implicitly adds .* context, making even anchored patterns quadratically complex. A separate FP on possessive quantifiers is also being investigated in SONARJAVA-6692.
java:S2447’s focus on nullable Boolean return types drew a well-argued challenge from @mirko.golfieri : the same NPE risk from auto-unboxing exists for Integer, Long, and Double, so why single out Boolean? You’re right that the risk is the same, and the rule description will be rewritten to explain the reasoning clearly, tracked in SONARJAVA-6683.
@tehnicaorg reported that Thymeleaf templates with message-expression concatenations like #{key} + 'suffix' cause the analyzer to fail and silently skip the file, then narrowed it down to a minimal reproducer. The bug is confirmed and a fix is in flight.
@MisterPi raised an interesting question about java:S2129: the rule recommends valueOf() over constructors, but new BigDecimal(String) is sometimes the clearest way to express a decimal with exact scale. This pattern is already excepted in the implementation, and SONARJAVA-6687 will update the rule spec to document it explicitly.
java:S7467 fires a false positive when an exception variable is used in a throw statement within the same catch block, and @Honza spotted this. Here goes SONARJAVA-6455!
@mvillanueva ran a meticulous investigation into why S6418 and S2068 don’t flag passwords containing “secret” in Ansible YAML, and uncovered a real gap: the YAML implementation of S2068 doesn’t yet respect the sonar.secrets.disableEntropyFilter override flag while the core Secrets analyzer does. A fix is in flight to align the behavior, and we’re grateful for the thorough detective work, @mvillanueva !
typescript:S4782 raises a false positive when an optional property’s type is imported from an external library, even though the rule is supposed to suppress issues in exactly that case, and @unblocker caught this while working with MUI’s TextField type in SonarQube for IDE. JS-2192 has been opened to fix it.
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!
Cheers,
Stevan