Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 00:48
    scala-steward opened #529
  • Sep 29 21:25
    scala-steward opened #528
  • Sep 29 21:25
    scala-steward opened #527
  • Sep 24 18:34
    scala-steward opened #526
  • Sep 22 21:00
    yujikiriki starred mwz/sonar-scala
  • Sep 21 22:55
    scala-steward opened #525
  • Sep 19 22:41
    mwz closed #524
  • Sep 19 22:40
    scala-steward opened #524
  • Sep 19 22:31

    mwz on master

    Update readme. (compare)

  • Sep 19 22:29

    mwz on v8.5.0

    (compare)

  • Sep 19 22:29

    mwz on master

    Setting version to 8.5.0. [ci s… Setting version to 8.6.0-SNAPSH… (compare)

  • Sep 19 22:14

    mwz on master

    Downgrade sonar api to 8.4.0. (compare)

  • Sep 19 22:10

    mwz on master

    Update SonarQube to 8.4 (#515) (compare)

  • Sep 19 22:10
    mwz closed #515
  • Sep 19 22:10
    mwz closed #492
  • Sep 19 20:38
    franbh synchronize #515
  • Sep 19 20:14

    mwz on master

    Update scalafmt-core to 2.7.2 (… (compare)

  • Sep 19 20:14
    mwz closed #523
  • Sep 18 17:30
    scala-steward opened #523
  • Sep 18 15:56
    leosilvadev starred mwz/sonar-scala
Michael Wizner
@mwz
:+1:
Robby Kiskanyan
@robbyki
@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/
Michael Wizner
@mwz
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
wei
@wei73905946_twitter
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
Michael Wizner
@mwz
@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
wei
@wei73905946_twitter
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
Michael Wizner
@mwz
you’re right, statement coverage seems to be missing there - thanks for reporting, I’ll have a look
wei
@wei73905946_twitter
thanks Michael
wei
@wei73905946_twitter
@mwz any updates on the issue of missing statement coverage? It will be great if you have ETA, thanks
Michael Wizner
@mwz
no updates yet I'm afraid, feel free to raise an issue on GitHub and I'll let you know there once I know more
wei
@wei73905946_twitter
Cosmin Ciobanu
@cosminci
@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>
Cosmin Ciobanu
@cosminci
I can create a PR with the fix if you can also reproduce it.
Michael Wizner
@mwz
I think the problem you have is the order in which you execute tasks. If you run tests first and then execute the scala:compile task to generate scapegoat report for sources the problem goes away.
Michael Wizner
@mwz
@/all sonar-scala 8.3 was released with support for SonarQube 8.3. New docker images can be found as always here.
Cosmin Ciobanu
@cosminci
That makes sense, I’ll give it a try. It’s somewhat non intuitive to run tests before compiling the sources so I never thought about it that way
Or rather, recompile the sources after running the tests
Michael Wizner
@mwz
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.
Cosmin Ciobanu
@cosminci
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?
Michael Wizner
@mwz
no this problem does not exist in sbt
cerst
@cerst
Hi, is there any special local configuration required for sbt-sonar (2.1.1) to work with SonarQube 6.7?
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)?
cerst
@cerst
Nvm ... i guess the problem must be our SonarQube: I've re-tried integration against mwizner/sonarqube-scala-plugins:2.12.0-full (instead of latest) and everything still seems to work
Michael Wizner
@mwz
I can’t think of anything specific that would break things for the combination of sonar-scala 6.8.0, SonarQube 6.7.x LTS and sbt-sonar 2.1.1, but I haven’t tested that particular combination.
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.
cerst
@cerst
Thanks for the response!
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 ...
Michael Wizner
@mwz
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.
cerst
@cerst
I gave it a try: mwz/sbt-sonar#117
Michael Wizner
@mwz
Thanks @cerst!
Michael Wizner
@mwz
@/all sbt-sonar 2.2.0 was released with the ability to toggle compatibility between sonar-scala and SonarScala plugins.
cerst
@cerst
awsome, thanks for the quick release :)
adityamenongithub
@adityamenongithub
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
Luis Miguel Mejía Suárez
@BalmungSan
@adityamenongithub it seems the plugin hasn't been updated for 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.
adityamenongithub
@adityamenongithub
Thanks for the reply @BalmungSan I'll try to give it a shot
Michael Wizner
@mwz
:+1:
adityamenongithub
@adityamenongithub
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
Michael Wizner
@mwz
Hey @adityamenongithub, that's strange this issue wasn't happening for me when I tested it. What version of SonarQube are you using?
adityamenongithub
@adityamenongithub
Version 8.4.2.36762
Michael Wizner
@mwz
Ok thanks I'll have a look. What os are you running it on?
adityamenongithub
@adityamenongithub
I am running it on a CentOS 7 running it via a docker thou docker pull sonarqube:8.4.2-community
Michael Wizner
@mwz
Can you also double check that this jar is readable by the sonarqube user in line with other plugins?
adityamenongithub
@adityamenongithub
Sure, I'll take a look at that too, Thank you so much for your quick response :)
Michael Wizner
@mwz
No worries, let me know if the permissions are fine then I'll have a look at my end. Maybe the release got corrupted somehow.
adityamenongithub
@adityamenongithub
@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