Warnings during processing LCOV report

[MartinKei]

Currently I get a lot of warn messages when running the analysis on our project. The error message goes like that:

Problem during processing LCOV report: can't save DA data for line 0 (Line with number 0 doesn't belong to file path/to/file.ts)

This happens also in the tests if you change the content of the angular.lcov file to contain more than one file analysis:

E.g. changing angular.lcov to :

SF:path/to/template/loader.js!path/to/file2.ts
DA:1,3
DA:2,0
DA:3,1
SF:path/to/template/loader.js!path/to/file.ts
DA:1,3
DA:2,0
DA:3,1
end_of_record

If you now run mvn test you'll get this output:

[...]
[INFO] Running com.pablissimo.sonar.CombinedCoverageSensorTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 s - in com.pablissimo.sonar.CombinedCoverageSensorTest
[INFO] Running com.pablissimo.sonar.LCOVParserImplTest
WARN  Problem during processing LCOV report: can't save DA data for line 0 (Line with number 0 doesn't belong to file path/to/file.ts).
WARN  Problem during processing LCOV report: can't save DA data for line 4 (Line with number 4 doesn't belong to file path/to/file.ts).
WARN  Problem during processing LCOV report: can't save DA data for line 0 (Line with number 0 doesn't belong to file path/to/file.ts).   
WARN  Problem during processing LCOV report: can't save DA data for line 4 (Line with number 4 doesn't belong to file path/to/file.ts).
[...]

TBH: I do not understand why this error occurs. To me it looks like it expects the lcov file to contain only output to the current file under analysis. Is this a bug or do I miss something here?

[Pablissimo]

Last-things-first: the output you're getting from mvn test is probably from the handlesOutOfRangeLineNumbers test which is explicitly designed to make sure the plugin doesn't crash entirely if an LCOV file claims execution of lines that are outside the range of lines in the file. Actually that test is using the outofrangefiles LCOV test file, which looks like this:

SF:path/to/file.ts
DA:0,3
DA:1,3
DA:4,3
end_of_record

i.e. if you just pull a clean copy from Git and mvn clean install test you're going to see that output.

The warning you're seeing in the first part of your message suggests that your LCOV file is reporting DA: lines against line 0 of at least one of your input files - this is problematic, as line numbers are 1-indexed. It happens sometimes via tooling that remaps LCOV via sourcemaps, where lines that can't be tracked back to a source TS line might be mapped instead to line 0. It is just a warning though, it shouldn't affect execution.

Any chance you can post the LCOV file section (SF: line until the next SF: line) of the file that's causing trouble? I'm betting that there's a DA:0, in there?

[MartinKei]

Still cloudy why we see this warning, but it's getting clearer - thank you!

i.e. if you just pull a clean copy from Git and mvn clean install test you're going to see that output.

Yes, that's true. My bad.

Any chance you can post the LCOV file section (SF: line until the next SF: line) of the file that's causing trouble? I'm betting that there's a DA:0, in there?

No, it's not.

But the warning still makes sense as it references lines which are not there. It seems that the lines are taken from the compiled JS instead if the TS file. The LCOV file contains references to line 25 although the typescript file has only 10 lines.

I think the problem boils down to an error on angular-cli code coverage setup. Do you have any expirence with using the code coverage from the regular angular-cli test --code-coverage call?

[Pablissimo]

I've not, no - as I understand it Karma and its remap-istanbul plugin should in theory be able to translate the JS line counts to TS equivalents, I'm not sure how remap-istanbul handles angular-cli LCOV files (the URLs are funky, but presumably it'll handle it)

I specifically added support for angular-cli though - #48 had examples of tooling people were using to do the translation if that's any help?

[MartinKei]

Yes, thank you. You have helped me already a lot!

Now, that it boils down to our tooling generating faulty lcov files I think we can close that issue.

Thanks, again.