Some TypeScript files claim "no coverage" in SonarCloud

[elliot-nelson]

Hello, we have a TypeScript repo using SonarCloud, and I’m encountering many files that seem to have no coverage. (Using SonarSource/sonarcloud-github-action from a GitHub Actions workflow, running on main branch in CI.)

We generate our lcov.info files using Jest, and according to Jest CLI the files have full coverage, but then in SonarCloud folders full of files have 0% or near-0% coverage. But other, sibling folders, configured the same way, have coverage matching Jest.

Example log intro from scanner:

INFO: Indexing files...
INFO: Project configuration:
INFO:   Excluded sources: **/build-wrapper-dump.json, */*/src/**/*.test.ts, */*/src/**/*.test.tsx
INFO:   Included tests: */*/src/**/*.test.ts, */*/src/**/*.test.tsx
INFO:   Excluded sources for coverage: */*/src/**/test/**/*.*, */*/src/**/__tests__/**/*.*, */*/src/**/__fixtures__/**/*.*, */*/src/**/__mocks__/**/*.*, */*/src/**/*.stories.tsx
INFO:   Excluded sources for duplication: **
INFO: Some of the project files were automatically excluded because they looked like generated code. Enable debug logging to see which files were excluded. You can disable bundle detection by setting sonar.javascript.detectBundles=false
INFO: 9732 files indexed
INFO: 9926 files ignored because of inclusion/exclusion patterns
INFO: 133 files ignored because of scm ignore settings

I ran with debug mode on, to check if anything was being excluded accidentally, or considered a test file, or detected as a bundle, or w/e; but I don’t see anything obvious. As an example, here are two log snippets…

THIS file appears covered in SonarCloud and Jest:

2023-08-17T10:59:03.2268831Z 10:59:03.225 DEBUG: 'apps/beam-ctv-enseo/src/packlets/platform-adapter/device.ts' generated metadata with charset 'UTF-8'
2023-08-17T10:59:03.2269504Z 10:59:03.225 DEBUG: file=/github/workspace/.git/.probe-1da8ccef-3a18-4563-933a-79102e1cf8d5, isRacyClean=true, read=2023-08-17 10:59:03.225465000, lastModified=2023-08-17 10:59:03.219567000, delta=5898000 ns, racy<=2500000000 ns
2023-08-17T10:59:03.2269858Z 10:59:03.225 DEBUG: file=/github/workspace/.git/.probe-1da8ccef-3a18-4563-933a-79102e1cf8d5, is racily clean
2023-08-17T10:59:03.2270284Z 10:59:03.225 DEBUG: 'apps/beam-ctv-enseo/src/packlets/platform-adapter/device.ts' indexed with language 'ts'
2023-08-17T10:59:03.2270744Z 10:59:03.225 DEBUG: File apps/beam-ctv-enseo/src/packlets/platform-adapter/device.ts excluded for duplication

But this file, although fully covered in Jest, has 0% coverage in Sonar:

2023-08-17T10:59:03.7709640Z 10:59:03.770 DEBUG: 'apps/beam-ctv-x1/src/packlets/platform-adapter/device.ts' generated metadata with charset 'UTF-8'
2023-08-17T10:59:03.7710274Z 10:59:03.770 DEBUG: 'apps/beam-ctv-x1/src/packlets/platform-adapter/device.ts' indexed with language 'ts'
2023-08-17T10:59:03.7710905Z 10:59:03.770 DEBUG: File apps/beam-ctv-x1/src/packlets/platform-adapter/device.ts excluded for duplication

Anyone have any idea what to investigate next? (The result today is developers are rapidly learning to ignore Sonar’s coverage suggestions which is not ideal.)

[Colin]

Hey there.

What do the logs say specifically about the import of code coverage?

How to find logs about importing code coverage

When coverage data isn’t appearing as expected in SonarQube / SonarCloud, the first place you should look is the scanner logs. Where do I find the scanner logs? This will likely be broken out into its own guide soon The Scanner logs are the output of executing one of the scanners, either directly or wrapped by one of many integrations, such as the SonarScanner for Jenkins, SonarScanner for Azure DevOps, SonarQube/SonarCloud GitHub Actions or SonarQube / SonarCloud Bitbucket Pipes. …

Do you see all LCOV files you expect to be imported represented in the logs?

[elliot-nelson]

Thanks for the pointer! So I looked specifically for LCOV and sure enough, I see a pile of errors (about 2300 lines of them). And they seem to be specifically on the files I am seeing with no coverage.

Here’s a snippet:

023-08-17T11:00:20.6710517Z 11:00:20.562 DEBUG: Problem during processing LCOV report: can't save DA data for line 200838 of coverage report file (java.lang.IllegalArgumentException: Line with number 153 doesn't belong to file GenerateAppPackageAction.ts).
2023-08-17T11:00:20.6711703Z 11:00:20.562 DEBUG: Problem during processing LCOV report: can't save DA data for line 200839 of coverage report file (java.lang.IllegalArgumentException: Line with number 160 doesn't belong to file GenerateAppPackageAction.ts).
2023-08-17T11:00:20.6712888Z 11:00:20.563 DEBUG: Problem during processing LCOV report: can't save DA data for line 202295 of coverage report file (java.lang.IllegalArgumentException: Line with number 52 doesn't belong to file start.ts).
2023-08-17T11:00:20.6713936Z 11:00:20.564 DEBUG: Problem during processing LCOV report: can't save DA data for line 202584 of coverage report file (java.lang.IllegalArgumentException: Line with number 8 doesn't belong to file index.ts).
2023-08-17T11:00:20.6714987Z 11:00:20.564 DEBUG: Problem during processing LCOV report: can't save DA data for line 202585 of coverage report file (java.lang.IllegalArgumentException: Line with number 9 doesn't belong to file index.ts).
2023-08-17T11:00:20.6716049Z 11:00:20.564 DEBUG: Problem during processing LCOV report: can't save DA data for line 202586 of coverage report file (java.lang.IllegalArgumentException: Line with number 16 doesn't belong to file index.ts).

I had previously looked at these LCOV files, and did not see any problems with them (because 90% of the repo does work!), but I think I have a new theory: since this is a monorepo with many projects, and we perform coverage at the project level, but run SonarCloud on the entire monorepo, it is getting hung up on “duplicate” files.

For example, from an lcov.info file:

TN:
SF:src/cli/Actions/GenerateAppPackageAction.ts
FN:29,(anonymous_6)
FN:43,(anonymous_7)
FN:98,(anonymous_8)
FN:103,(anonymous_9)
FNF:4
FNH:0

This file is actually (from the root of the repo) tools/tizen-tools/src/cli/Actions/GenerateAppPackageAction.ts. But there is another file with the same relative path, in a different project, and I think Sonar is confusing this 160-line file with a different file that is 120 lines.

If my theory is correct, running a script that converts all relative paths in LCOV files into absolute paths before running the Scanner should fix the issue… I’ll give it a try!

[elliot-nelson]

It worked! That was indeed the problem, editing all lcov.info files so that file paths were relative to the root of the repo fixed the issue.