@mwz in general and in terms of static analysis, how does the sonar-scala plugin using scalariform differ from the static analysis scanner we currently have in sonar? https://docs.sonarqube.org/latest/analysis/languages/scala/
I wrote about this briefly some time ago, but haven’t done any recent comparison
https://github.com/mwz/sonar-scala/issues/179#issuecomment-477719803
on top of that from the most recent features the most significant one is pull request decoration which is available in sonar-scala for free (in comparison with SonarScala), you can read more about it on the website https://sonar-scala.com/docs/setup/pr-decoration
https://github.com/mwz/sonar-scala/issues/179#issuecomment-477719803
on top of that from the most recent features the most significant one is pull request decoration which is available in sonar-scala for free (in comparison with SonarScala), you can read more about it on the website https://sonar-scala.com/docs/setup/pr-decoration
Hi all, just a qq, how do I configure SonarQube dashboard to show statement coverage and branch coverage for scala projects, https://sonar-scala.com/docs/about/supported-metrics
@wei73905946_twitter You need to configure scoverage in your project, you can find an example on the website https://sonar-scala.com/docs/setup/getting-started#quick-start
Yes, I follows the instruction on the website. I also looked at all projects here: https://sonar.sonar-scala.com/projects?sort=-analysis_date
only sonar-scala-lts project have statement coverage, all other scala project don't
@mwz I’m was still fascinated as to why in https://github.com/mwz/sonar-scala/blob/master/examples/mvn/multi-module/pom.xml scapegoat is not running against the tests but only the sources, and it really looks like it has the same problem I see
Scapegoat does run against the test source and does override the source reports when I run the example on local, unless I feed it different
-P:scapegoat:dataDir for the compile and testCompile goals
If I run
mvn clean install on local on the sample project with no changes, the resulting scapegoat.xml files in the module target directories contain no issues.
It made no sense for maven to be any different from gradle in this regard, looking at sksamuel/scapegoat#254
the fix is to do something like
<executions>
<execution>
<id>source-compile</id>
<goals>
<goal>compile</goal>
</goals>
<configuration>
<args>
<arg>-P:scapegoat:dataDir:${project.build.directory}</arg>
</args>
</configuration>
</execution>
<execution>
<id>test-compile</id>
<goals>
<goal>testCompile</goal>
</goals>
<configuration>
<args>
<arg>-P:scapegoat:dataDir:${project.build.directory}/tests</arg>
</args>
</configuration>
</execution>
</executions>
Or rather, recompile the sources after running the tests
yeah in fact that’s how the example project is set up to run - https://github.com/mwz/sonar-scala/blob/master/examples/scan.sh#L42
It’s not a proper solution but a workaround that I settled on. I don’t use mvn so I didn’t want to invest much time into fixing this properly, but if you have a fix them I’d be happy to accept a PR.
It’s not a proper solution but a workaround that I settled on. I don’t use mvn so I didn’t want to invest much time into fixing this properly, but if you have a fix them I’d be happy to accept a PR.
I’m actually considering doing the same workaround rather than keeping the complexity in the pom. It’s particularly painful when you’re using extra scalac plugins as you need to maintain both a common configuration with the common set of arguments as well as particular configs for each execution with
combine.children / combine.self properties to make sure maven merges everything as expected. Perhaps it’s better just to add an extra observation to the readme that explains why it’s mandatory to specify the scala:compile goal after the test goal. What do you think?
Also, any idea if, and if not - why, this problem does not manifest for
sbt?
Hi, is there any special local configuration required for sbt-sonar (2.1.1) to work with SonarQube 6.7?
When i run
Or does that mean that the server has an incompatible (plugin) version (referring to the sonar-scala compatibility matrix in the docs)?
When i run
sonarScan against the docker container listed in the documentation everything works but i loose (at least) all coverage data when running against our 6.7 SonarQube.Or does that mean that the server has an incompatible (plugin) version (referring to the sonar-scala compatibility matrix in the docs)?
If you’re installing sonar-scala manually then check v6.8.0 against your SonarQube instance, that’s the version that’s bundled in the
sonarqube-scala-plugins:2.12.0-full image.
Also I’d recommend migrating to the latest SonarQube LTS if you can as 6.7 is no longer supported.
Thanks for the response!
Unfortunately, i can't do anything about the SubarQube version ...
However, i could fix the problem by adding the following
In my case this causes a FileNotException during
I can't say why this works but maybe it'll help someone else ...
Unfortunately, i can't do anything about the SubarQube version ...
However, i could fix the problem by adding the following
sonarProperties entry to the root module of the multi module build:"sonar.scala.coverage.reportPaths" -> sonarProperties.value("sonar.scala.scoverage.reportPath") (note that it is coverage.reportPath*s* instead of *s**coverage.reportPath)In my case this causes a FileNotException during
sonarScan because the root module has no sources and thus no coverage reports. But the coverage reporting now works.I can't say why this works but maybe it'll help someone else ...
Then it would appear that you’re using the SonarScala plugin rather than sonar-scala.
There is an incomplete PR in sbt-sonar (mwz/sbt-sonar#45) which attempts to make sbt-sonar compatible with SonarScala so that you don’t need to fiddle with those path properties. It hasn’t been finished off by the author, so if you’re keen to contribute it’s an easy one to pick up.
There is an incomplete PR in sbt-sonar (mwz/sbt-sonar#45) which attempts to make sbt-sonar compatible with SonarScala so that you don’t need to fiddle with those path properties. It hasn’t been finished off by the author, so if you’re keen to contribute it’s an easy one to pick up.
@/all sbt-sonar 2.2.0 was released with the ability to toggle compatibility between sonar-scala and SonarScala plugins.
Hi All, I setup Sonarqube 8.4 and tried to install the sonar-scala plugin 8.4 version and it started to fail :(
java.lang.IllegalStateException: Unable to read plugin manifest from jar : is there a way I can make sonar-scala 8.4 version work with the latest Sonarqube.
1 reply
@adityamenongithub it seems the plugin hasn't been updated for
Also, you can build that plugin locally and use it until the official release is done.
8.4 yet, you may open a PR upgrading the dependency and fixing any build / test errors you find; I am sure Micahel will be grateful for that and release a new version ASAP.Also, you can build that plugin locally and use it until the official release is done.
Hi @mwz since my SBT skill are the worst my friend @franbh helped me with the pull request for the new SonarQube compatibility with
8.4 mwz/sonar-scala-docker#28 I took the new jar file from https://dl.bintray.com/mwz/maven/com/github/mwz/sonar-scala_2.13/8.5.0/sonar-scala_2.13-8.5.0-assembly.jar and added it to the plugins directory with the same error java.lang.IllegalStateException: Unable to read plugin manifest from jar : /opt/sonarqube/extensions/plugins/sonar-scala_2.13-8.5.0-assembly.jar
at org.sonar.updatecenter.common.PluginManifest.<init>(PluginManifest.java:125)
at org.sonar.core.platform.PluginInfo.create(PluginInfo.java:412)
at org.sonar.server.plugins.ServerPluginRepository.loadPreInstalledPlugins(ServerPluginRepository.java:135)
1 reply
@mwz forgot to let you know about this, I couldn't get the jar working so I used the docker image https://hub.docker.com/r/mwizner/sonarqube-scala-plugins and looks like its working for me and seems like a better way than the jar. Thanks for your help