Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The file has no scoverage information associated with it. #56

Closed
dmarkhas opened this issue May 7, 2018 · 20 comments · Fixed by #57
Closed

The file has no scoverage information associated with it. #56

dmarkhas opened this issue May 7, 2018 · 20 comments · Fixed by #57
Labels
Projects

Comments

@dmarkhas
Copy link

@dmarkhas dmarkhas commented May 7, 2018

We're using version 6.2.0 of the plugin, but when running the sonarqube task from Gradle it seems that it somehow fails to parse the scoverage.xml report, even though it finds it and loads it successfully.

These are the errors I am seeing:

[scoverage] Initializing the scoverage sensor.
[scoverage] Successfully loaded the scoverage report file: 'C:\Users\dmarkhas\IdeaProjects\sdk-base\build\reports\scoverage\scoverage.xml'.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/Launcher.scala' has no scoverage information associated with it.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/application/AbstractSparkApplication.scala' has no scoverage information associated with it.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala' has no scoverage information associated with it.

I saw #51 but in this case the filenames match exactly the filenames in the xml report so I'm not sure what's wrong. I've attached the scoverage report (had to rename from .xml to .txt for GitHub) - anything obvious I am missing perhaps?

scoverage.txt

@BalmungSan

This comment has been minimized.

Copy link
Contributor

@BalmungSan BalmungSan commented May 7, 2018

Hello @dmarkhas, could you run the plugin in debug mode and paste the output here?

But, probably the issue is due you're running on windows, and the ScoverageSensor does not support windows yet!.

(@mwz, IMHO, we should focus on fixing the incompatibility with windows ASAP.)

@dmarkhas

This comment has been minimized.

Copy link
Author

@dmarkhas dmarkhas commented May 7, 2018

I thought so too, but running it on Linux resulted in the same issue. I am now playing around with the code a bit and it seems that the moduleCoverage.filesCoverage map is empty.
I believe it is a bug introduced by this commit: 7173142#diff-6bfed6247dd6c81a3cc573964ccf73b3

Specifically, this piece of code in ScoverageReportParser seems to be at fault:

      filename <- sourcePrefixes.collectFirst {
        case prefix if cwd.resolve(prefix).resolve(scoverageFilename).toFile.exists =>
          prefix.resolve(scoverageFilename)
      }

Given the following parameters:
sourcePrefixes : ["src/main/scala"]
scoverageFilename : "src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala"

This tries to resolve the path cwd/src/main/scala/src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala

Which is wrong, since the filename already contains the prefix :)

@BalmungSan

This comment has been minimized.

Copy link
Contributor

@BalmungSan BalmungSan commented May 7, 2018

Uhm... yes, you're right. Could you try the following piece of code?

filename <- sourcePrefixes.collectFirst {
  case prefix if cwd.relativize(cwd.resolve(Paths.get(prefix))).relativize(Paths.get(scoverageFilename)).toFile.exists =>
    cwd.relativize(cwd.resolve(Paths.get(prefix))).resolve(scoverageFilename)
}
@dmarkhas

This comment has been minimized.

Copy link
Author

@dmarkhas dmarkhas commented May 7, 2018

That doesn't compile for me.. I assume you're using java.nio.file.Paths? in that case the get method accepts either a String or a URI, while prefix is Path. I tried prefix.toURI and that didn't work..

@BalmungSan

This comment has been minimized.

Copy link
Contributor

@BalmungSan BalmungSan commented May 7, 2018

Oh sorry I forgot that, you could use prefix.toString.

Edit
Oh wait, prefix is already a Path so Paths.get(prefix) is unnecessary. Thus the code becomes:

filename <- sourcePrefixes.collectFirst {
  case prefix if cwd.relativize(cwd.resolve(prefix)).relativize(Paths.get(scoverageFilename)).toFile.exists =>
    cwd.relativize(cwd.resolve(prefix)).resolve(scoverageFilename)
}

I'm sorry for the confusion. Could you try it again?

PS: This is just for making a quick test/fix. I will make PR for fixing this in a couple of days.

@dmarkhas

This comment has been minimized.

Copy link
Author

@dmarkhas dmarkhas commented May 7, 2018

Unfortunately that didn't work. I think the underlying issue is that the filename in the scoverage.xml already contains the prefix "src/main/scala", making the prefix actually redundant.
In my case, simply checking if cwd.resolve(scoverageFilename) exists is sufficient, and then simply setting filename to be scoverageFilename works.

No changes would be needed if there was any way to remove this prefix from the filename in the generated scoverage.xml report, but there doesn't seem to be any such option in the gradle plugin.

@BalmungSan

This comment has been minimized.

Copy link
Contributor

@BalmungSan BalmungSan commented May 7, 2018

Yes, you're right.
I'm sorry, I'm a bit busy so I not taking the time to look at this properly thus I got confused 😞.

We're having a big problem here:
When using SBT the scoverage filenames are relative to "src/main/scala".
When using Gradle they are relative to the project root.
When using Maven they are absolute path.
Also they are dependent to the SO ('\' vs '/').

Uhm...
This will be difficult to handle.

@mwz Any thoughts?

@dmarkhas, sorry again for not being of much help, when I have time I will work in this.

@dmarkhas

This comment has been minimized.

Copy link
Author

@dmarkhas dmarkhas commented May 7, 2018

I really appreciate your help :-)
In the meanwhile we can keep using my simplified forked version.

Perhaps checking if the scoverageFilename begins with the prefix and then stripping it out would work?

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 7, 2018

Hi @dmarkhas, thanks for reporting the issue. It sounds like your suggestion to strip out the prefix from the filename should work, so it's worth giving it a try.

It's a shame that there are so many inconsistencies between different distributions of sonar scanners and scoverage plugins... this certainly doesn't make our life easier and it starts slowly to feel like we're doing cross-browser development 😆

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 10, 2018

@dmarkhas, thanks for waiting and testing the latest changes in #57 - I'll make a new release as soon as #54 gets merged.

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 12, 2018

@dmarkhas - 6.3.0 is out. Feel free to let us know if you have any more issues.

@freshka

This comment has been minimized.

Copy link

@freshka freshka commented May 14, 2018

Problem occurs for multi modules projects (works properly for projects without modules)

sonar-project.properties:
sonar.modules=output-adapter,commons
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml

output:
12:02:17.765 INFO: [scoverage] Successfully loaded the scoverage report file: 'output-adapter/build/reports/scoverage/scoverage.xml'.
12:02:17.765 DEBUG: [scoverage] Saving the overall scoverage information about the module, the statement coverage is 97.56%.
12:02:17.767 DEBUG: [scoverage] Saving the scoverage information of the file: 'output-adapter/src/main/scala/dummy/adapter/output/CepTicketProvider.scala'
12:02:17.767 WARN: [scoverage] The file: 'output-adapter/src/main/scala/dummy/adapter/output/CepTicketProvider.scala' has no scoverage information associated with it.

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 14, 2018

Hi @freshka, thanks for letting us know that you're having issues.

Would you mind sharing with us some more details about your setup like e.g. which build tool you're using, how your multi-module project is structured, your full sonar-project.properties file and how you're executing the analysis?

Would you also be able to confirm that you've set the sonar.scala.scoverage.reportPath property for each module and that Scoverage generates a report within each module and you're not aggregating the reports into one?

@freshka

This comment has been minimized.

Copy link

@freshka freshka commented May 15, 2018

Hi @mwz
I'm using Gradle with gradle-scoverage:2.3.0

Project structure example:

commons
--src
----main
----test
--build.gradle
output-adapter
--src
----main
----test
--build.gradle
build.gradle
settings.gradle (include all modules here)

Analize execute by Jenkins (SonarQube Scanner v. 3.0.3.778) and scoverage reports not aggregated. Sonar-scala plugin cannot find files but properly read report as i said above:
12:02:17.765 DEBUG: [scoverage] Saving the overall scoverage information about the module, the statement coverage is 97.56%.

sonar-project.properties:
sonar.projectKey=cep_adapter
sonar.projectVersion=01.003
sonar.modules=output-adapter,commons
sonar.sources=src/main/scala
sonar.tests=src/test/scala
sonar.java.binaries=build/classes/main,build/classes/test
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml
sonar.sourceEncoding=UTF-8
sonar.locale=ru_RU

@BalmungSan

This comment has been minimized.

Copy link
Contributor

@BalmungSan BalmungSan commented May 15, 2018

Hello @freshka,

If the reports are not aggregated, that means there is one report per module, is that correct?

Also, could you please provide us one of the scoverage files? (If they contain sensitive information that you wouldn't like to share, we only need the filename attribute of one class tag)

@freshka

This comment has been minimized.

Copy link

@freshka freshka commented May 15, 2018

Hi @BalmungSan
Yes, one scoverage report per module, report located in a module directory (for example output-adapter/build/reports/scoverage/scoverage.xml)

<class name="dummy.adapter.output.CepTicketProvider" filename="src/main/scala/dummy/adapter/output/CepTicketProvider.scala" statement-count="36" statements-invoked="36" statement-rate="100.00" branch-rate="100.00">

filename is relative to module path, not to project root

@sinwe

This comment has been minimized.

Copy link

@sinwe sinwe commented May 15, 2018

The issue that @freshka encounter is exactly the same as mine. I'm waiting for the fix of this

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 17, 2018

Hi @freshka, @sinwe - apologies for the wait. I've merged a fix for your issues and am hoping to do a little bit more testing against any regressions, but you can expect a new release most likely sometime over the weekend.

@sinwe

This comment has been minimized.

Copy link

@sinwe sinwe commented May 18, 2018

@mwz I appreciate the effort you've put into it. I'll wait for the new release

@mwz

This comment has been minimized.

Copy link
Owner

@mwz mwz commented May 27, 2018

@sinwe, @freshka, just to let you know that 6.4.0 was released a couple of days ago and it should fix your Gradle issues with multi-module projects.

You can also find an example of a multi-module project built with Gradle here and here is the result of SonarQube analysis with coverage reported for each module.

Thanks again for reporting the issue and please feel free to let us know if you come across anything else.

@mwz mwz closed this May 27, 2018
@mwz mwz added this to Done in sonar-scala Jul 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
sonar-scala
  
Done
5 participants
You can’t perform that action at this time.