they are only focussing a specific part of the repository content
they are using the Sonar properties that are either defined directly in the root pom file, or in a root sonar-project.properties file that the pom file reference
the configuration performed at SonarQube Cloud level are overloaded by the ones specified in one of those files
the scan policy not being overloaded, we still use our company default one, which is the default sonar one (Sonar Way ?)
what is automatically reported in our Pull Requests is coming directly from that kind of scaning
In order to shift left, and have a shorter feedback loop, I’ve installed the Sonar Qube IDE plugin on my Intellij
Unfortunately, I’ve tried both bounded (I.E. “Bind project to SonarQube” active), and unbounded modes, but couldn’t achieve having the plugin reporting the same things that what I get in our PRs :
When running it in unbounded mode I’ve noticed that there is at least the latest rules defined regarding Java time bugs that are not applied
When running it in bounded mode, I do get those Java time bug related rules applied, but in that case, as mentioned in the documentation, the plugin doesn’t care of the pom file configuration, and apply the configuration from the SonarQube Cloud side … which don’t really use, I.E. which is the default one
This explains that I also have all other directories sitting next to my root src directory that are also scanned, and thus comes polluting the report, sometimes with many things we d’ont really care about
When checking what is reported on the PR side, the rules related to the Java time bugs are indeed taken into account, as well as the specific sonar properties that we defined in the pom file
So I’m puzzled, and wondering if there is any way with the plugin to achieve the same thing than what is reported by our PRs ?
Hey @Mumeii, you’re right: SonarQube for IDE doesn’t read properties from pom.xml or similar configuration sources. To have the same configuration, you mainly have 2 options:
In connected mode, move the properties you have in pom.xml to the SonarQube Cloud-side, per-project UI configuration (Analysis Scope / File Exclusions in project settings). The IDE extension downloads these settings via the project binding.
In standalone mode (not bound), copy the properties you have in pom.xml in the SonarQube for IDE settings.
I will nonetheless flag this for the PMs so that they are aware of your feedback, it’s important for us to hear how this is a source of friction for you.
Indeed, it’s very problematic from my point of view, because we’re very “shift left” oriented at workd
I.E., we favor using a file from the project repository being the configuration reference for Sonar, as it spare us to change of tool : going back and forth between our IDE and browser
But what is very puzzling for me here is that no matter this configuration source problematic, I still don’t understand why the stand alone mode doesn’t have the latest Java 8 dates related rules running, whereas the default policy used by SonarQube Cloud does
Ah yes the Java date rules, sorry, I forgot to address that! Rules used when not in connected mode can be configured by going to IntelliJ’s global settings > SonarQube for IDE (under the Tools section) > Rules tab. Here you can see the rules, and you can search them based on the rule’s name. For example, I can see in SonarQube Cloud that S5917’s name is “DateTimeFormatters should not use mismatched year and week numbers”, I can look it up in the SonarQube for IDE settings, and I can enable or disable it.
Could you check if these rules are enabled for you? If they are but they’re still are not being raised, then please update to the latest version of SonarQube for IDE (latest is 12.4, you’re on 12.3), try again, and if still no luck, then please share the code snippet with us.
Ok, so I start to understand a bit better, thanks to your help !
First of all, after updating to 12.4, I now have Java date & time rules working fine in unbound mode. I.E. fine in the way that they are all reported as long as they are ticked in the SonarQube for IDE rules menu :
So for example I get quite a lot of java:S8692 reported, because #legacy :
We’ve badly conceived our tests in the first place, and now we use a lot of .now( * ) here and there in this part of our code
But on the other hand, I don’t have those java:S8692 reported in bounded mode, because from what I understand, this rule is flagged as inactive in the `Sonar way Java (Built-in)` default profile we’re using
So to sum it up :
you’ve solved my Java date related rules trouble : simply update my plugin was the solution. I think it’s because the rule set got updated relatively recently that I’ve missed that one
I still experience discrepancies between bounded and unbounded mode, because of two problematics :
my .pom file specific configurations are not taken into account whenever triggering a scan, no matter I’m in bounded or unbounded mode
the set of default rules activated in the plugin is distinct from the one of `Sonar way Java (Built-in)` profile
Thank you for your help understanding what was going on
On top of the .pom specific configuration that you’ve proposed to report to the Sonar PMs, a few feature ideas :
Enable to easily configure rules in the IDE plugin in order to conform to the Sonar way default mode, on a per language basis
Add a tab in the scan’s report windows explaining a bit in which context it got run, as one can get confused after opening many of them in different mode. For example, specifying which rule configuration got used :
Sonar Way or custom policy in Bounded mode, local rule set in unbounded mode is from the report, . It coule, and over which scan perimeter
Over which part of the file system
With which scan parameters
From where those parameters are from
Add a tool that can explain why a rule ID is or is not considered during a scan
. It coule, and over which scan perimeter