Illustrate how to use sonar-scanner with the Gradle multi-module example
carlspring opened this issue · comments
Hi,
Would you mind providing an example of how to use the sonar-scanner to publish the reports for the scanning of the multi-module examples to Sonarqube? Is this at all possible for mutli-module projects (using the sonar-scanner)?
Doing this works fine from Gradle using gradle --no-daemon clean test reportScoverage sonarqube.
It seems that the sonar-scanner isn't able to automatically figure out the locations for Scoverage and Scapegoat reports, or understand:
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml,module1/build/reports/scoverage/scoverage.xml,module2/build/reports/scoverage/scoverage.xml
sonar.scala.scapegoat.reportPath=build/reports/scapegoat/scapegoat.xml,module1/build/reports/scapegoat/scapegoat.xml,module2/build/reports/scapegoat/scapegoat.xml
Please, advise!
Thanks in advance!
Martin
I did. It works flawlessly that way! We have a generic tool which wraps aroung the sonar-scanner. My impression (please confirm, or correct me) is that the sonar-scanner is now a thing of the past and should only be used as a last resort, if your build tool does not have its own built-in (or plugin) support for publishing reports to Sonarqube.
I have been trying to get it to work with the sonar-scanner to see how the results differ. My understanding is that the Gradle Sonarqube plugin works better and that it handles the aggregations itself and knows exactly what to do, whereas the sonar-scanner is a generic report publisher which needs a lot of tweaking to make it work, especially, for multi-module projects.
Could you please confirm which one is is the standard, (or better to use)?
Thanks a lot! :)
Hi @carlspring sorry if you already read my last response, didn't get your problem at first.
Had you already tried only setting the properties on the root level only?
The scanner should search for the same relative path on each module, like how we do on the SBT multi-module example (which uses sonar-scanner).
It would be great, if you could provide a sonar-project.properties with a couple of lines of instructions on how to execute it with the sonar-scanner.
This is what I have:
sonar.projectName=sonar-scala-gradle-multi-module
sonar.projectKey=examples:sonar-scala-gradle-multi-module
sonar.projectVersion=1.0-SNAPSHOT
sonar.sources=src/main/scala,module1/src/main/scala,module2/src/main/scala
sonar.tests=src/test/scala,module1/src/test/scala,module2/src/test/scala
sonar.sourceEncoding=UTF-8
sonar.scala.version=2.12
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml,module1/build/reports/scoverage/scoverage.xml,module2/build/reports/scoverage/scoverage.xml
sonar.scala.scapegoat.reportPath=build/reports/scapegoat/scapegoat.xml,module1/build/reports/scapegoat/scapegoat.xml,module2/build/reports/scapegoat/scapegoat.xml
I'm seeing less reported issues (that when using the Gradle example with the Sonarqube plugin) and there is no code coverage.
I'm assuming there must be a better way than to have to list the directories for the modules one by one, but, so far, I haven't found the proper combination.
Can you please try this?
sonar.projectName=sonar-scala-gradle-multi-module
sonar.projectKey=examples:sonar-scala-gradle-multi-module
sonar.projectVersion=1.0-SNAPSHOT
sonar.sources=src/main/scala
sonar.tests=src/test/scala
sonar.sourceEncoding=UTF-8
sonar.scala.version=2.12
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml
sonar.scala.scapegoat.reportPath=build/reports/scapegoat/scapegoat.xml
sonar.modules=module1,module2
module1.sonar.projectName=Module 1
module2.sonar.projectName=Module 2
Okay, thanks! But... what happens, if you have tons of modules? Do you have to list them all one by one?
Brilliant! This works!
As to my original questions:
- Could you please confirm what is best to use when publishing to Sonarqube (the Gradle plugin, or the
sonar-scanner; the reasoning would really help us make a decision and I think we need to migrate to the Gradle plugin approach)? - When using the
sonar-scanner, is it possible to not have to list the modules and their names one by one, like in the example above? Is there a better way involving less manual configuration?
"My impression (please confirm, or correct me) is that the sonar-scanner is now a thing of the past and should only be used as a last resort, if your build tool does not have its own built-in (or plugin) support for publishing reports to Sonarqube".
Not sure if it is really dead, but certainly it is being replaced by plugins using the sonar-scanner-api, there is work in progress to do the same with the SBT plugin, which is the only one (for Scala, that I know) that still relies on sonar-scanner itself.
"It would be great, if you could provide a sonar-project.properties with a couple of lines of instructions on how to execute it with the sonar-scanner".
It should be the same as the one used for SBT, only changing the paths to match the ones generated by your build tool.
Probably, once the SBT plugin uses the api too, we wont need the properties file for our examples.
Maybe we should add an example that uses the sonar-scanner CLI... but, which build tool should compile the project and execute Scapegoat & Scoverage?
Maybe, we should add two variations of each example - what do you think @mwz?
"Could you please confirm which one is is the standard, (or better to use)?"
Unfortunately, the only place where I touch Gradle are those examples.
Thus, I can say which one is most common / standard.
But, since the plugin handles modules more easy I would really stick to it.
"Okay, thanks! But... what happens, if you have tons of modules? Do you have to list them all one by one?"
As far as I know, yes.
However, again, those examples are the only multi-modules project on which I work. So, I do not have many experience with them.
Hopefully, Michael will have a better understanding on that matter.
I think I covered everything that you had asked so far, If I missed something just say it
Thank you very much for this detailed explanation! It really helps to understand the whole Sonar mess (which is not well documented and typically has documentation that is not up-to-date).
For our projects, we're using Gradle to compile our Scala code. However, thanks for providing the explanation regarding SBT, as this will certainly be of use to others trying to figure it out.
Maybe, we should add two variations of each example - what do you think @mwz?
I think it would be worth it to have the two alternatives illustrated and adding the useful parts of this conversation to the README.md-s of the examples would probably help others in the future.
This definitely confirms my theory that we need to consider updating our processes and move away from the sonar-scanner (except for the projects that use languages with poorer support in their build tools).
Thanks again! :)
The way I see sonar-scanner cli is more like a backup option in case there is no plugin/package available for your build tool, otherwise, it's definitely better to use the more specialised plugin as it will be optimised for the specific build tool and will simply integrate better. The most obvious benefit of using the specific plugins is that they can infer a lot of default settings for you like the project name, key, version, etc. so using those makes things a bit easier.
+1 for extra examples, however, this isn't something that's high on my priority list, but I'd be happy to accept PRs if anyone is keen to contribute those.