We are dealing with a situation where we generate a .h file that includes different parts of our code depending on the target of our build.
In order to analyze all of our code, we have been advised to use sample .h files to simulate different targets and to run successive analyses with those files instead of our generated file, while changing the name of the project with each analysis to represent the different use cases.
That seems to make sense, but we do not see the project name change anywhere.
We are passing -Dsonar.projectName=projectName-XXX to the scanner, where XXX changes between the different .h configurations. The project key stays the same.
What is the issue here? Is that the best practice to handle such a case? Where are we supposed to see the project name change?
Thanks
Using SonarQube 9.1.0.47736, no extensions or plugins
sonar.projectName is purely aesthetic, while sonar.projectKey represents a different (unique) technical key that identifies the project.
What I think you’re trying to accomplish would better be accomplished by having separate projects (meaning different SonarQube projects each with a different sonar.projectKey).
I realize the project name change would be only visual, but It would have help our devs distinguish between the anayses for the different targets. But as it stands, the project name change doesn’t seem to affect anything…
Concerning your suggestion, would the global sonar line count count the duplicated lines of code? We’re working with a big project (X00k lines), and simply cannot afford to have that number multiplied by 9 (our number of targets)…
Additionally, how would I go at setting up a project for a gitlab repository that is already in use for a sonar project?
Currently, some users are working as if each configuration of analysis was a different branch of the project. This way, you don’t pay for duplicated lines of code, but the user experience might not be ideal.
Also thanks for linking the feature request, I will absolutely upvote it.
So having multiple project is not viable without upgrading our licence, which is out of our budget.
Using multiple branches is technically feasible, but we already have a lot of feature branches, as you said, the ux will be absolutely terrible for our devs, the number of operations and merge requests will make people very unhappy.
So, we need to either multiply our sonar budget by >10 or annoy our devs to the point they won’t want to use it? There is no other way for now?
For now, I’m only aware of one other solution (which is another trade-off, not something perfect, I’m acutely conscious of that): Don’t analyze all 9 configurations for the full source code.
Usually, some configurations are pretty close to each others, analyzing just one of those might already provide you most of the insight without paying too much of a price?
Usually, most of the code is platform independent, a small part is platform-specific. Analyzing this small part 9 times, and the full project just once, might already provide you most of the insights while still paying a reasonable price?