This is rly painful, combined to the fact that the only way to find about this parameter is to go to the project settings screen, but this screen does not exist, you can only setup “general settings”, which of course is not ok, it has to be set at project level.
We moved our information for coverage exclusions to our documentation on narrowing the scope. sonar.coverage.exclusions is omitted and is meant as an undocumented setting, as we recommend setting this for the project in the UI.
Let me know if you have any questions or thoughts on that.
Can you please tell me what you plan for this “undocumented” setting ? Will it be deprecated soon ? Or will you acknowledge it’s just a mistake and add a line to the doc with your recommandations and the reasons behind these recommandations ?
This setting was purposely removed from the documentation. The setting itself will most likely not be deprecated because it is still used by the UI when coverage exclusions are set there. We made this change to encourage the use of this setting in the UI as opposed to setting and forgetting in a scanner configuration file.
You should be able to set sonar.coverage.exclusions in the UI on the project level. From the project’s Overview page, go to Administration>General Settings>Analysis Scope. Coverage exclusions is the first setting on that page. If you can’t get to the project’s administration menu, or if it doesn’t show up, you might need to double check if you have administrative privileges for that project.
Well, with this explanation, it’s still hard to understand why you mention other parameters like “sonar.exclusions” which could as well “bet set and forgotten in a scanner configuration file” and not “sonar.coverage.exclusions”
I think most users would benefit from more consistency, and I think the best way to achieve consistency would be to mention all non-deprecated parameters, and not to delete them all.
Anyway, I’d like to add some context to this thread.
Many moons ago I was the dope who initially added the exclusions settings to the documentation. And after many, many attempts to help users here in the community who were struggling with them (which can sometimes be “rly painful”), I’m the one who took them out.
Why? Because
they can be difficult to set correctly
including them in the list of analysis parameters seems to encourage users who are trying to tick all the boxes to set them - whether or not they actually need them
Okay, you’re right that when we re-worked the project homepage, we did miss a documentation update in the path-through-the-UI that we list to get to these settings. Where it says, for instance
Administration > General Settings > Analysis Scope > Issues .
You need Project Admin rights to see the menu item on the project homepage. If you don’t see that but you do have the global Administration menu item, then you can use those global rights to hook yourself up with project-level perms.
Nope. No plan to deprecate this.
Nope. Not a mistake. Done completely on purpose, for the reasons stated above.
In fact, I’ve stated those reasons here in this community (and in other places, such as SO - love when people downvote me for it!) until I’m blue in the face. It doesn’t seem to help.
In fact, those few mentions in the Narrowing the Focus page are intended to direct you to the correct input in the UI. But you’re right; we should probably remove them too.
In closing, and since you’re both new to the community, I’d like to point out that this is a community. We’re a group of people who try to help each other. That works best when we all try to be civil, and helpful, and come to it with our best intentions, and assume that everyone else is doing the same. That’s what Josh has been doing, but perhaps I didn’t tick all those boxes in my response today. We all fail sometimes. Let’s all try to do better.
To sum it up : some users where struggling to set parameters correctly and felt like they had to fill all of them because they were listed in the documentation, so you removed the parameters from the documentation, at least some of them, to solve the problem.
When people (with reputation ?) on SO made it clear they didn’t agree with this choice, you chosed to ignore them.
Well, I have some reputation on SO too (https://stackoverflow.com/users/668455/tristan) and I disagree with this choice too, I don’t think hiding informations is a way to solve any problem. It may not make you reconsider your choices, but at least, I’ve respectfully given my community member opinion.
Moreover, there is a bigger inconsistency : project developpers with no admin rights can set up the parameters, but they can’t access those set in the UI, nor know which precedence applies between conf parameters and UI parameters.
In my opinion, the best way to adress all these issues would be to explain the different possibilities, the precedence which applies, and then tell your recommandations and the reasons for them (in the documentation, not in the forums). See how the most upvoted answer on SO gives all the informations (pom conf and UI) : https://stackoverflow.com/a/27133765/668455, and how the official documentation throws a shadow on the deprecation of some parameters.
Let me be clear. There are many parameters that can be overridden via analysis properties that have never been listed in the docs. We provide an interface for setting them. The fact that you can override them at the analysis level is … let’s say a bonus.
Yes, you’re right. IMO developers should have admin rights on their projects, but that’s out of my hands.