-
Notifications
You must be signed in to change notification settings - Fork 787
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
Istanbul/coverage reporter generate LCOV file with relative path for SF parameter instead of absolute path #104
Comments
http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php However istanbul is generating a releative path. gotwarlost/istanbul#104 refix can help fix this issue by prefixing with an absolute path. prefix currently prepends ./ to the prefix which makes it a releative path and breaks it on windows. fixes mdasberg#1
I know what the spec says, but should this be a security concern at all? I mean check this path on the sample, and now I'm noticing it in all my projects. |
@drkibitz , absolutely - showing absolute paths in reports is terrible from a security viewpoint. |
Closing this - reopen if still an issue. I agree with @drkibitz 's security concerns, |
Anyone else dealing with this again? I'm seeing the same issue again with the latest version v0.3.5 |
seems to be a problem again yeah |
Facing same issue, are there workarounds so that lcov.info has relative paths instead? |
+1 for using absolute paths (sonarqube expects that). |
+1 For sonarqube I use a dirty hack by running this sed command
in between the unit tests and sonar scan. Because my build runs in docker container I can get away with hard-coding absolute path /app |
-1 for absolute paths. In my recent experience, Sonar works perfectly fine with relative paths, so long as you configure sonar-project.properties properly. But with absolute paths, you're stuck with an lcov.info file that can only be used in one location. My build pipeline zips up enough of the current working build directory so I can run the Sonar analysis in a complete independent build job. The absolute paths make this impossible, as they point to a specific build directory path. At the very least, there should be an option to choose absolute or relative. |
I don't quite get why sonarqube expects absolute paths. We can run tests on one job on some machine and ran report analysis on some different machine. Absolute paths are acceptable in some cases but in some others they definitely are not. |
+1 for having an option to choose between absolute and relative |
@benjamine and @gotwarlost I have sent a PR (#771) requesting with precisely this feature. I hope to revisit this topic. |
@vladistan and @miguelrincon any work around for this in teamcity? I need to make a similar thing for teamcity. Is there any command like sed available for teamcity? I tried the below but it fails
gives error
Lcov with absolute path TN: I need to update this path *E:\a03\work\bb52cb33e083fc9\src* to relative Before running sed command SonarQube failed with error
Installed Versions
|
To provide another example passed off @vladistan 's logic:
I'm adding this in the execute shell phase in the "Build" phase in jenkins after I run the tests. |
Is there another way to get relative paths now? Our build is within a docker container separate from where analysis are run which is failing because it cannot find the JS files. |
It would be great if there was a way to have an option to toggle which behavior we want. Relative as default and absolute as option. |
We are using Istanbul with Karma to generate a javascript code coverage report. We are using "lcovonly" option for the reporter type.
At present, the file generated by Karma/Istanbul contains a relative path for the SF parameter of lcov.info while it must be an absolute path. (see http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php)
This is causing problems when we try to read this lcov file with sonar javascript plugin because the source files are not found.
We finally end to "patch" some source files of istanbul in order to fix this problem for lcovonly, but I think this should be done for lcov also.
What modifications ?
This way lcov file generated has absolute path for SF in lcov.info.
Could this be taken into account for the next version of Istanbul. It will save us a lot of time ? I don't think it is a big fix.
This bug is similar to karma-runner/karma#528, but was not fixed.
The text was updated successfully, but these errors were encountered: