Documentation about "Ignore Issues" seems to be wrong or outdated

https://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus#NarrowingtheFocus-IgnoreIssues claims

Note that the properties below can only be set through the web interface because they are multi-valued

But Google actually finds example configurations like https://github.com/liflab/cornipickle/blob/master/sonar-project.properties that do

# Ignore a few rules
sonar.issue.ignore.multicriteria=e1,e2,e3,e4,e5

# Field names should comply with a naming convention
sonar.issue.ignore.multicriteria.e1.ruleKey=squid:S00116
sonar.issue.ignore.multicriteria.e1.resourceKey=**/*.java

# Variable names should comply with a naming convention
sonar.issue.ignore.multicriteria.e2.ruleKey=squid:S00117
sonar.issue.ignore.multicriteria.e2.resourceKey=**/*.java
[...]

And that seems to work just fine.

Would be nice to document this on the page referenced above.

4 Likes

We recommend users to use the UI to configure this, for best experience. Consider the configuration via sonar-project.properties as an undocumented hack, not official supported that may or may not work reliably, use at your own risk.

A post was split to a new topic: Ignoring certain rules in certain directories

Hi Janos,

Can I ask why this is considered a hack and not officially supported?
From an engineering point of view, it makes absolute sense to keep this configuration close to the codebase and the build pipeline configuration. Same as our linting config overrides are also configured in code.

If this feature not support because it’s not fully developed yet or are the no plans to offer this as an officially supported feature?

5 Likes

If I recall correctly (and I can be wrong on this), the app provides a nice UX, and the configuration using the file is complex, poor UX.

I’ll contact our PMs to chime in here. (It might take a while due to holidays.)

Hello @ChrisR,

We consider it a hack because of the reasons that @janos mentioned in his message. Having that type of configuration in a properties file can be error-prone and difficult to maintain, which is also why we do not advocate for it in our documentation.

I agree that keeping this configuration close to the code makes sense for a lot of projects, but right now there are no short-term plans of larger changes on this topic.

But this is much easier to store in a VCS and to copy. I have several projects where I’d like to ignore similar issues. In the UI I have to do N clicks each time. Is the official support of the properties considered for the (near) future?

4 Likes

That makes literally no sense, consistently configuring over 50 projects manually through a UI is vastly more error-prone and difficult to maintain than sharing configuration as code.

12 Likes

Absolutely agree with Chris and Fml2, this should be configurable through a file. Moreover, the UI should provide a quick way to obtain file configuration strings for a particular issue type (e.g. I want to mute it). I hope you will change your opinion @janos, @Martin_Bednorz.

3 Likes

Any news on this topic? People now have application code in versioned repositories, infrastructure as a code versioned the same way, but we should not maintain sonar rules in the codebase because it is considered a “hack”? With a ludicrous argument that clicking through a Web UI is more maintainable and comfortable? Isn’t this a tool for software engineers? Am I missing something?

5 Likes

Agree with others here, this really needs to be configurable as code. Clicking around and typing into a web interface to set rules for this is the very definition of “error prone and difficult to maintain”, not the other way around! This is a tool for software developers, right?

4 Likes

Same thing here, especially because even the “hack” seems not to work on sonarCloud.

I can’t deploy sonar at an organization level if we have to click in the UI for every single repo we have (our situation is that we’ve kind of strict rules for production code and would allow a bit more permissive scan for test files).

Another solution would be to apply a different profile based on path patterns but it doesn’t seem to be supported neither. :frowning:

2 Likes

Configuration should be in code per project. If you have a nice UI - ok cool, but that’s not a per project solution.

Actually, there should be nothing that’s configurable in the UI. What you should enforce is a configuration location for the org that is VCS backed, then any UI updates can be audited. But these should just be for the defaults across the org.

Any project should be able to override with project based properties. And sonar should be warning people that do UI configuration updates that they should set up a VCS and prefer configuration in code!

3 Likes

Sorry about commenting while not adding any new insights to the thread. But I wanted to give a big ‘plus 1’ on the aforementioned reasons for having things first and foremost in VCS.

1 Like

Hi @Martin_Bednorz,
I really have hard times to understand, why such text based configurations are absent. How would you handle a situation, where you have to have different rules on different branches? (Maybe due to migrations or workaround for bugs in external libraries / tools)

best regards,
Torsten

1 Like

Any word on this? #70868