Hello Community!
This time, the roundup is prefaced by an announcement that affects not only those of your who use product X, or who are interested in feature Y. This time it’s something that all of you, Sonar Community members, can participate in: our Sonar developer survey, which is now open and calling for responses. Once you’ve done that, you can relax watching a new Sonarflix episode Learning Center video on our SonarQube Hunter Agent!
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 user saw their corporate antivirus quarantine the SonarQube Cloud scanner engine jar as a Trojan. @manuel-valino reported the detection with the full hash details and ESET report, which made tracking this down much faster. ESET has confirmed it was a false positive and will fix it in their next detection engine update. Thanks for all that legwork!
Rules & Languages
docker:S8431 complained about Docker image references that combine a version tag with a digest, even though that’s exactly the format Dependabot and Renovate need to produce clean, readable upgrade PRs. @rkrisztian made the case clearly with real before-and-after diffs. We’ve already updated the rule so tag-and-digest references no longer trigger it in projects with a supported Dependabot or Renovate configuration file. Nice catch!
java:S6829 only recognized @Autowired for constructor injection, missing that Spring also supports the JSR-330 @Inject annotation. @Nyamiou pointed this out with a clean reproducer. We’ll start recognizing both javax.inject.Inject (Spring 5) and jakarta.inject.Inject (Spring 6+). SONARJAVA-6912 was created as a result.
go:S1186 forced a comment or workaround onto every intentionally empty no-op method, even when the empty body itself was the implementation. @andy-super walked us through real production examples of Noop/Fake/Disabled types. Thanks for the detailed follow-up! We’re adding a configuration property so these naming idioms can be recognized as self-documenting.
cpp:S1121 flagged Boost.Parameter’s named-argument syntax, like setUp(_value = 1), as an assignment buried inside an expression, even though that’s the library’s intended calling convention. You’re right, @hintsch, that’s a false positive, and we’re on it.
Copying a volatile field, or writing a copy constructor for one, made java:S3078 fire and suggest switching to AtomicInteger, which wouldn’t even fix a real concurrency issue. @ikaronen flagged this with a striking data point: 14 violations in their codebase, all false positives of this exact type. SONARJAVA-6911 was created to fix it.
S2699 didn’t recognize Jasmine’s expectAsync as a valid test assertion, so tests using it were incorrectly flagged as having no assertions at all. @otjrocks spotted this and went above and beyond by opening a PR with the fix, and @victor.diez merged it right away. Thanks to you both!
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!