NaN in coverage report

[rwehresmann]

Did someone face the same?

      - name: Back-end test coverage report
        uses: romeovs/[email protected]
        with:
          title: Back-end test coverage report
          filter-changed-files: true
          delete-old-comments: true
          lcov-file: ./coverage/app.lcov
          github-token: ${{ secrets.GITHUB_TOKEN }}

[sdhull]

Same issue here. I switched to cobertura formatter & action

[keithlayne]

I got the same thing, because the program outputting my lcov files was missing LH and LF:

At the end of a section, there is a summary about how many lines were found and how many were actually instrumented:
LH:<number of lines with a non-zero execution count>
LF:<number of instrumented lines>

(from http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php)

So, check your actual lcov files for these entries. This action depends on lcov-parse, which will cause lines.files.hit and lines.file.found to be zero for every entry, causing lots of divide-by-zero and thus NaNs.

[phylor]

There is a pull request on simplecov-lcov to add LH and LF. Until that is merged, you could use the fork:

  gem 'simplecov-lcov', require: false, github: 't-mario-y/simplecov-lcov', branch: 'feature/write-LF-LH'

[hramrach]

So this is not compatible with lcov?

I create my report with

lcov --capture --base $(pwd) --no-external --directory . --output-file coverage.info

and get NaNs in the output.

[hramrach]

And apparently when multiple captures are merged the LH/LF records are generated, and merging an initial capture with a test capture is needed to get any usable data at all.