SonarQube for IntelliJ plugin version: 10.19.0.80823
PyCharm version: 2024.3.5
Programming language you’re coding in: Python
Is connected mode used: Yes - SonarQube Server Enterprise Edition Version 10.3 (build 82913)
Our enterprise provides a SonarQube server for multiple projects to use, we are not permitted to update the rules so we make use of sonar-project.properties to ignore rules. PyCharm when bound to the server does not honor those properties so all the rules we ignored should up, and since it is bound turning the rules off in PyCharm configuration has no effect.
# Comma-delimited list of ignored code smell rules
# https://sonarqube.accenturefederaldev.com/coding_rules?languages=py&selected=python
# https://docs.sonarsource.com/sonarcloud/advanced-setup/analysis-scope/#rule-key-pattern
sonar.issue.ignore.multicriteria=e1,e2,e3,e4
# python:S117 Local variable and function parameter names should comply with a naming convention
sonar.issue.ignore.multicriteria.e1.ruleKey=python:S117
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*.py
# python:S116 Field names should comply with a naming convention
sonar.issue.ignore.multicriteria.e2.ruleKey=python:S116
sonar.issue.ignore.multicriteria.e2.resourceKey=**/*.py
# python:S1542 Function names should comply with a naming convention
sonar.issue.ignore.multicriteria.e3.ruleKey=python:S1542
sonar.issue.ignore.multicriteria.e3.resourceKey=**/*.py
# python:S100 Method names should comply with a naming convention
sonar.issue.ignore.multicriteria.e4.ruleKey=python:S100
sonar.issue.ignore.multicriteria.e4.resourceKey=**/*.py
Thanks for sharing the configuration file. I guess what I was asking was: are you expecting it to be picked up automatically, or did you try to configure its use somehow?
If I don’t have the project bound to Sonar then the properties file is picked up and the excluded rules are excluded with no custom config on my part. When I bind to the server the the properties file is not picked up.
On the Sonar Server it is making use of the properties file so the ignored items are properly ignored.
This is expected. When you’re in connected mode, one of the features is that the settings saved on the server are applied in-IDE. This includes Quality Profiles and things like exclusions.
Running analysis with exclusions specified in a properties file applies them for that analysis. It does not save them server-side. And thus, they’re not there to be applied in connected mode.
So that is where I’m stuck. I’m prohibited from modifying the server which is why I’m using the properties file. But that makes binding in the IDE useless since all the ignored rules show up.
If I unbind I loose the benefit of some of the other checks but I guess I don’t have a see of highlighted warnings.
Hello,
I have the same problem, although I’m using IntelliJ IDEA and not PyCharm.
However, I’m not sure I’ve understood what is the “expected” behavior of this plugin, or at least the rationale behind it.
In my company, we have a SonarQube server, where all our projects are scanned. If I log into the SonarQube server web UI, I can see the results of the scan. These results are honoring what I’ve written in the sonar-project.properties file, including rule exclusions, and whatsoever. Moreover, I can mark issues as "false positive"s or “won’t fix”, etc.
Then, I installed the plugin, so that I can intercept issues earlier compared to the current workflow (which is: push to our git repository, this triggers a CI build with Jenkins, which in turn triggers an updated scan on the SonarQube server, where I can see the results). So, I connected the plugin to our SonarQube server hoping that what I see on the web UI is exactly what I will see in the IDE. But, because of this problem, it seems it’s not the case. So I was wondering what is the “right” way of using this plugin to get the exact same reporting I get on the server (+ earlier feedback when I have outgoing changes pending).
When you connect SonarQube for IDE to SonarQube Server / Cloud, our understanding is that you want to apply the data at the server to your local experience. So the remote settings take precedence over your local ones.
On the other hand, during analysis, we follow a last-saved-wins sort of model, and give the values set most closely to the analysis command the highest precedence (diagram here).
And once I’ve said it that way, I do see the contradiction.
I’ve flagged this for the PMs, but I wouldn’t hold my breath if I were you.
In the meantime, your best bet is to have a project admin apply on the server the values you’ve set in your properties file.
So, this sounds like a design flaw to me, or at least it makes the IDE plugin work in a different way compared to what was our expectation (i.e.: to see exactly the same results of analysis conducted on the server, but in the IDE, so earlier). I’m not sure I understand the benefits of the current approach. The main problem here, after talking about this with our operation team, is that changing the server settings for all our projects (which are countless) is not sustainable and goes against the advantage and transparency given by persisting the configuration-as-code in git along with each project.
Massive here. I just started using the SQ plugin, and ran into this straightaway. This decision flies in the face of the SQ configuration model, which specifically allows the use of property files to override or extend global and project settings. See Settings Hierarchy. Fortunately, unlike the OP, I do have access to project settings, but managing our config on a per-project basis instead of a single baselined project properties file unnecessarily complicates our workflow. Honestly, I’m not sure the hassle is worth the effort.
Hi @phalverson ! Thank you for sharing your perspective. We completely understand the frustration when a workflow you’ve refined feels restricted by the plugin’s behavior.
The shift toward prioritizing server-side settings over local .properties files is a deliberate design choice aimed at Governance. Here is the reasoning behind that approach:
Consistency is Key: When local configurations override server settings, it’s easy for a developer to inadvertently disable a rule or change a threshold locally. This leads to a ‘Works on My Machine’ scenario where the local analysis passes, but the code fails the Quality Gate (QG) once pushed to the server.
The ‘Single Source of Truth’: By tethering the local analysis to the server settings, we ensure that every developer on the team is held to the exact same standard. It allows admins to set global expectations that are automatically synced to everyone’s IDE.
Reducing Maintenance: While it might feel like more work upfront to set these in the UI, it actually prevents ‘configuration drift’ across large teams where dozens of different local property files might otherwise need to be managed.
We want the local experience to be a mirror of the server’s expectations so there are no surprises at the finish line. That said, we appreciate the feedback on how this complicates your specific baselined workflow, and we’ll keep it in mind as we continue to evolve the configuration model.
If you have any ideas on how we could improve our configuration to make it easier for you, please share the desired workflow and we are happy to consider this with our team.
here. I just started using the SQ plugin, and ran into this straightaway. This decision flies in the face of the SQ configuration model, which specifically allows the use of property files to override or extend global and project settings. See