ci: Add coverage.yml workflow

[ValuedMammal]

A recent CI run can be found here https://github.com/bitcoindevkit/bdk-tx/actions/runs/15537664175/job/43740556358.

[nymius]

Do you have in mind a second use of the lcov.info file other than source it to genhtml? Why not using -t html?

[nymius]

Giving a second look at this, I think lcov.info may be useful to generate diffs between master and the merging branch, but I've not found a good tool to display reports from these diffs.

[nymius]

Also, I would remove the --branch flag. I don't know if your are getting any results there, but from my experience the matching column for those is usually 0/0, so not giving useful information. It seems to be not supported actually: mozilla/grcov#520

[nymius]

I have been testing grcov for bdk-sp and explored different combinations of flag to get the most of coverage reports:

• --excl-start "#\[cfg\(test\)\]": In all the bdk repositories I have seen unit test are placed at the end of files, and not in the middle like some projects (correct me if I'm wrong). So I think this flag is useful in this case. I wouldn't use --excl-br-line "^\s*#\[cfg\(test\)\].*" for these cases because I've experimented with it, and it ignores all #[test] tagged functions, but the utility functions inside the test module are not ignored, altering the final report numbers.
• --excl-br-line "^\s*((debug_)?assert(_eq|_ne)?!|#\[derive\()": In this case I'm not so sure about the debug_assert and assert variations, as it may be used in some parts of the target code with actual implications in main logic of the program, but I don't have much of these in the code I have been using to test. In the case of derive I think is useful to exclude them in the case of default derivations. That code is boilerplate and cannot unless implemented manually, in which case the lines will be considered by the coverage report.
• --excl-line "^\s*\S+\s*(=>)?\s*unreachable!.*": I have some actually legit cases to use unreachable, so as long as the macro is not used lightly, I think is a good way to improve the signal of the report.

[nymius]

After adding docstrings to bdk-sp encoding module, grcov started to produce some false positives, so I started looking at other tools.
I ended up deciding with cargo-llvm-cov because it doesn't have those false positives, and also is able to ignore unit test code.
Although this is possible thanks to nightly attributes, as these tools are exclusively for the developing phase, and not release, I think it is OK to use nightly for these use cases.
cargo-llvm-cov also improves reports by adding branch coverage (thanks to nightly).
--mdcd gives errors on ci so --branch is enough for now.

[ValuedMammal]

Thank you @nymius I'll do some more research on cargo-llvm-cov.