Istanbul: Istanbul/coverage reporter generate LCOV file with relative path for SF parameter instead of absolute path

[flambert70]

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 ?
1) /usr/lib/node_modules/karma-coverage/node_modules/istanbul/lib/report/lcov.js

 29 function LcovReport(opts) {
 30     Report.call(this);
 31     opts = opts || {};
 32     var baseDir = path.resolve(opts.dir || process.cwd()),
 33         htmlDir = path.resolve(baseDir, 'lcov-report');
 34     //patch
 35     var rootDir = path.resolve(opts.root || process.cwd());
 36     mkdirp.sync(baseDir);
 37     //patch
 38     //this.lcov = new LcovOnlyReport({ dir: baseDir });
 39     this.lcov = new LcovOnlyReport({ dir: baseDir, root: rootDir });
 40     this.html = new HtmlReport({ dir: htmlDir, sourceStore: opts.sourceStore});
 41 }

2) /usr/lib/node_modules/karma-coverage/node_modules/istanbul/lib/report/lcovonly.js

 function LcovOnlyReport(opts) {
 27     this.opts = opts || {};
 28     this.opts.dir = this.opts.dir || process.cwd();
 29     this.opts.writer = this.opts.writer || null;
 30     //patch
 31     this.opts.root = this.opts.root || process.cwd();
 32 }
...
 45         writer.println('TN:'); //no test name
 46         //patch
 47         //writer.println('SF:' +fc.path);
 48         writer.println('SF:' + this.opts.root + fc.path.replace(/\./,''));

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 https://github.com/karma-runner/karma/issues/528, but was not fixed.

[drkibitz]

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.

http://gotwarlost.github.io/istanbul/public/coverage/std-lcov/Users/ananthk/screwdriver-git/istanbul/index.html

[gotwarlost]

@drkibitz , absolutely - showing absolute paths in reports is terrible from a security viewpoint.

[gotwarlost]

Closing this - reopen if still an issue. I agree with @drkibitz 's security concerns,

[CodisRedding]

Anyone else dealing with this again? I'm seeing the same issue again with the latest version v0.3.5

[pocesar]

seems to be a problem again yeah

[vptech20nn]

Facing same issue, are there workarounds so that lcov.info has relative paths instead?

[sonemonu]

+1 for using absolute paths (sonarqube expects that).

[vladistan]

+1

For sonarqube I use a dirty hack by running this sed command

sed -i.bak 's@^SF:/app/@SF:@' coverage/lcov.info

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

[RobotLimeLtd]

-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.

[RachelSatoyama]

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.

[benjamine]

+1 for having an option to choose between absolute and relative

[miguelrincon]

@benjamine and @gotwarlost I have sent a PR (#771) requesting with precisely this feature. I hope to revisit this topic.

[MuraliM]

@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

$workdir="%teamcity.build.checkoutDir%"
sed -i -- 's/\/$workdir/Web.Spa/app/g' coverage/report/lcov.info

gives error

sed: -e expression #1, char 23: unknown option to `s'

Lcov with absolute path

TN:
SF:E:a03workbb52cb33e083fc9srcWeb.SpaappHistoryhistory.service.js
FN:5,(anonymous_1)
FN:6,HistoryService
FN:8,(anonymous_3)
FN:9,(anonymous_4)

I need to update this path *E:a03workbb52cb33e083fc9src* to relative

Before running sed command SonarQube failed with error

Could not resolve file paths

[14:20:53][Step 13/13] INFO: Integration Test Coverage Sensor is started
[14:20:53][Step 13/13] INFO: Overall Coverage Sensor is started
[14:20:53][Step 13/13] INFO: Analysing [E:a03workbb52cb33e083fc9srcWeb.Spacoveragereportlcov.info]
[14:20:53][Step 13/13] INFO: Sensor JavaScript Squid Sensor [javascript] (done) | time=13034ms
[14:20:53][Step 13/13] WARN: Could not resolve 44 file paths in [E:a03workbb52cb33e083fc9srcWeb.Spacoveragereportlcov.info], first unresolved path: E:a03workbb52cb33e083fc9srcWeb.SpaappHistoryhistory.service.js

Installed Versions

"jasmine-core": "2.8.0",
"karma": "^1.3.0",
"karma-chrome-launcher": "^2.0.0",
"karma-cli": "^1.0.1",
"karma-coverage": "^1.1.1",
"karma-coverage-istanbul-reporter": "^1.3.3",
"karma-jasmine": "^1.0.2",
"karma-jasmine-html-reporter": "^0.2.2",
"karma-teamcity-reporter": "^1.1.0",

[michael-mckenna]

To provide another example passed off @vladistan 's logic:

  pattern="/usr/src/app/"
  replacement="output/myName/src/app"
  sed -i "s@$pattern@$replacement@g" output/coverage/lcov.info

I'm adding this in the execute shell phase in the "Build" phase in jenkins after I run the tests.

[jsmithe]

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.

[donmahallem]

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.