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.

6 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.

1 Like

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?

6 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?

5 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.

16 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.

4 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?

6 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?

7 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!

4 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.

2 Likes

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

3 Likes

Any word on this? #70868

Any news on this topic?

I have to agree with @fml2 and @ChrisR . Such things should be possible to version and keep in VCS, along with other config. I hope you reconsider this, as itā€™s just more convenient to keep all the configs in one place, with the project codebase.

Thanks,
Paula

1 Like

We are just starting our journey with SonarQube across about 100 projects. The comments earlier from others nail the problem. This will be a significant impediment to our adoption if itā€™s not going to work.

Also, there is a lifecycle problem that canā€™t overstated. Code changes in different branches will have different scanning needs. A given branch may add new exclusions or remove them, depending on what changed in the branch. And, code reviewers will want to be able to evaluate what exclusions will be appropriate after a given branch is merged.

Using the UI means all branches need to always share a consistent state for their exclusions. Thatā€™s a clearly-problematic usage plan.

Hi @tkent,

The documentation has been moderated from the initial quote posted in 2018. We recommend you set this exclusion from the UI because many people find it tricky to get right, and it often leads to frustration on both sides.

That said, the syntax in the OP should work.

Would you mind explaining your use case here? Settings at the project level, rather than the branch level, are a deliberate choice on our side. We donā€™t see the use case for having different settings for different branches of the same project. Would you mind explaining what your use case is?

 
Ann

:wave: Ann,

Off the top of my head, I can point out three scenarios where this will be a problem. For each, assume weā€™re following the SonarQube recommended path of having scans be a part of our CI build pipelines. For each build on each branch, we get SonarQube feedback. Failures cause the pipeline to fail, making sure we deal with problems early while itā€™s still inexpensive to do so.

Scenario 1: A developer renames some code on a branch where an exclusion applied.

If we have a master list of exclusions for the SonarQube project, not changing at the same rate as the code, then we have a problem. The exclusions will no longer apply and cause our SonarQube scan to fail. Now the developer has two options:

  1. Add a new, temporary rule to the project for the rename. And then try to remember to remove the rule after all branches with the previous code are retired. Of course, this wonā€™t happen.
  2. Ignore the sonarqube failure. At which point, why have the scan?

Scenario 2: Code is refactored on a branch. New exclusions apply, previous ones no longer apply

Again, we have the same problem, except now you canā€™t just add a rule. The most likely scenario is that the developer will remove the old exclusion and add their new one (directly or through an admin). This will break all other in-flight branches or force the developer to change their design to avoid a SonarQube limitation.

Scenario 3: A developer removes an exclusion after a change on a branch.

A developer is upgrading some code. With the new code, an exclusion is no longer needed and they want to see if they can remove the exclusion with their changes. They must delete their exclusion to test this.

Now, all other in-flight branches are broken until the exclusion is put back or the change is pushed through all branches.

Also, in each of these scenarios, the SonarQube exclusion changes are invisible to the dev team. Itā€™s not in the code, so itā€™s not in the PR/MR changes. There are no comments as to why a given rule is excluded in the UI, no change history that can be used by the developers.

This is pretty surprising. Rule exclusions using path selectors are based on the configuration of the code being scanned, and branches are different. Both where the code is located may change and what exclusions make sense may change. It would be more surprising if all your path patterns and exclusion needs stayed the same across all your branches all the time.

Keeping these exclusions in code makes sense and seems like a pretty common theme. Not just on this thread, but this other thread, this SO post, in an actual project, etc. Basically, there is a lot of examples of people needing this use case if you do a quick google search.