The lcov 'spec' (which is really just a manpage) says that '-' is a valid value for the fourth token in a BRDA line. It means "code containing branch was never executed, so branch could never have ben taken" as opposed to "branch not taken". Certain coverage tools like geninfo will output "-". This confuses lcov-result-merger into thinking that the branch hit total is NaN.

See the relevant section:

Branch coverage information is stored which one line per branch:

      BRDA:<line number>,<block number>,<branch number>,<taken>

    Block number and branch number are gcc internal  IDs  for  the  branch.
    Taken  is either ’-’ if the basic block containing the branch was never
    executed or a number indicating how often that branch was taken.

    Branch coverage summaries are stored in two lines:

      BRF:<number of branches found>
      BRH:<number of branches hit>

I use nyc to test nodejs and karma-typescript to test browser and merge the result with lcov-result-merger.
the line coverage report is correct, but the branch coverage report are not

there are 2 issues.

1. nyc block id starts with 0 : BRDA:29,0,0,8, but karma-typescript starts with 1 : BRDA:29,1,0,8. so they are completely mismatched and creates lots of extra branches in the report
2. different compiling setting may cause some branch to disappear due to compiler optimization, so 2 report might have different number of branches, and in that case block id are also mismatched.

my work around is to unify block id base on the current source line instead of current source file, so every time BRDA reach a new source line, it reset block id to 0 .

my script to unify the block id:
https://github.com/ticlo/ticlo/blob/master/tool/unify-lcov.ts

this should solve most of the issues.
I guess it's still possible that even in same line, one compiling setting may finds 3 branches and the other finds only 2 branches. in that case it's just impossible to merge correctly since lcov doesn't have the information of the begin and end of a branch

See man page for info.

Apparently istanbul is generating those identifiers nowadays.

https://travis-ci.org/mweibel/lcov-result-merger/jobs/350177702

[Semantic release]: The release type for the commit is major
[Semantic release]: Analysis of 2 commits complete: major release
[Semantic release]: The next release version is 3.0.0
[Semantic release]: Call plugin verify-release
[Semantic release]: An error occurred while running semantic-release: Error: No callback provied.
    at exports.default (/home/travis/build/mweibel/lcov-result-merger/node_modules/cracks/dist/index.js:23:11)
    at Object.verifyRelease (/home/travis/build/mweibel/lcov-result-merger/node_modules/semantic-release/lib/plugins/normalize.js:41:26)
    at run (/home/travis/build/mweibel/lcov-result-merger/node_modules/semantic-release/index.js:68:17)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:118:7)

What kind of patterns are supported? I'm trying to merge lcov.info files on 2 different directories using the following pattern on stdout:
/app/static_build/coverage_reports/frontend/**/lcov.info

We run lcov-result-merger on a remote system, after updating to 5.0.0 we get the following error:

[Error: EXDEV: cross-device link not permitted, rename '/tmp/lcov-result-merger-abc/lcov.info' -> './coverage/lcov.info'] {
	errno: -18,
	code: 'EXDEV',
	syscall: 'rename',
	path: '/tmp/lcov-result-merger-abc/lcov.info',
	dest: './coverage/lcov.info'
}

Im posting this here as I guess that others will come across this too.
The problem is easy solvable by adding the flag legacy-temp-file, e.g.:

./node_modules/.bin/lcov-result-merger './coverage/**/lcov.info' './coverage/lcov.info' --legacy-temp-file

@mweibel would you like to retain publishing control for the repository?

For some reasone version 4 does not output anything when run like bellow:
V4.0.0 - npx lcov-result-merger "C:\temp\CodeCoverage**\lcov.info" "C:\Temp\CodeCoverage\lcov.info"

version 3.3.0 works as expected
npx [email protected] "C:\temp\CodeCoverage**\lcov.info" "C:\Temp\CodeCoverage\lcov.info"

Do we have plans for rolling the next release? Is there any blocker? Any help wanted?

We have breaking changes like dependency updates and dropping support to older versions on Node. Should we bump it to 4.0.0?

Using lcov-result-merger (1.2.0) to combine coverage reports from targets running the same binary, the report loses the function coverage that can be seen in the individual report generated from each target separately.

My workflow was as follows:

1. Build binary on build-machine
2. Copy the build tree (with .gcno files) to target1 and target2
3. Run program on each target
4. Run lcov -d . -c --to-package coverage_target1 on target1
5. Run lcov -d . -c --to-package coverage_target2 on target2
6. Copy coverage_target1 and coverage_target2 to build-machine
7. Run lcov --from-package on the copied files (creating target1.info and target2.info)
8. Run lcov-result-merger on the two .info files, creating merged.info
9. Run genhtml on target1.info, target2.info, and merged.info

genhtml summary on target1.info:

Writing directory view page.
Overall coverage rate:
  lines......: 23.6% (6883 of 29121 lines)
  functions..: 19.9% (1537 of 7724 functions)

genhtml summary on target2.info:

Writing directory view page.
Overall coverage rate:
  lines......: 36.2% (10549 of 29121 lines)
  functions..: 25.0% (1929 of 7724 functions)

genhtml summary on merged.info (output of lcov-result-merger):

Writing directory view page.
Overall coverage rate:
  lines......: 39.1% (11398 of 29121 lines)
  functions..: no data found

Note that the function coverage is missing from the merged result.

Thanks for sharing the lib. Before incorporating I wanted to give it a simple try to ensure that everything works fine.

Here either I'm missing something, or the results are corrupted during the merge. Repro steps are simple, just exec couple of commands:

• wget https://gist.githubusercontent.com/mlewand/6ad97f21f07ce1e215f9565f7cefa4ad/raw/b8a39cdc544a17acddc9516a32fb2a3ee1dd284c/lcov.info && touch combined_lcov.info
• npx lcov-result-merger lcov.info combined_lcov.info
• diff lcov.info combined_lcov.info

Expected

The two files should be equal (diff should not print any output).

Actual

Files are different.

Other information

Based on path you can see that it has been executed on Windows (10) os.

What's the license of the project?

Given a repository directory structure like this, from a Flutter project:

lib/component.dart
test/component_test.dart
packages/module1/lib/module1.dart
packages/module1/test/module1_test.dart
packages/module2/lib/module2.dart
packages/module21/test/module2_test.dart

Then will run programs that generates the .lcov files first (in this case flutter test --coverage) and want to combine all the lcov.info files into a central overview.

I used lcov-result-merger '**/lcov.info' coverage/combined.info. That produced a valid file but discarded the relative path to the source files references in the sub directories, leading to genhtml errors like this:

❯ genhtml coverage/combined.info -o coverage/html    
...
genhtml: ERROR: cannot read /Users/user/git/com.company.app/lib/module1.dart

I think that lcov-result merger should try to adjust the subdirectory path to "module1.dart", so that genhtml tries to resolve packages/module1/lib/module1.dart instead.

@mweibel

Hi,
I'd like to use this but the merge policy is not what i'd need.
Could it be possible to customize the merge "policy"? Instead of adding up the values, i'd like to pick the suite with the best result when the same file is tested.
This could be an argument when running the script: policy=sum or policy=best

What do you think?

Node is at v10 now.

Lcov-result-merger blocks the whole build due to it's limitation in package.json to node versions <= 9.

I imagine this tool still works with the newest version of node, please remove the artificial limit