0
votes

I'm not a front-end developer, but I need to get a sonarqube scan working with unit test coverage. All of this WAS working, but we had a big SonarQube version upgrade (6.x to 7.9.1), and it was broken for a while, and now I'm trying to get it working again.

As this used to work, what we have must be close, but there's some detail that isn't quite right.

When the build runs, it runs the unit tests and appears to generate coverage data, and the call to "sonar-scanner" sends the path to the lcov.info file. In the SonarQube project, it has a large number of "lines to cover", but with the same number of uncovered lines. I also note that it doesn't have a "Unit Tests" section in the overview.

In the build output, I see quite a few lines like this:

DEBUG: 'src/api/Api.spec.tsx' indexed as test with language 'ts'

But as noted above, the SonarQube project doesn't appear to think there are any unit tests.

As part of the build script, at the end of the tests run, I ran "ls -lt coverage" to see what was generated, and it showed this:

total 6264
-rw-r--r-- 1 81050 20059 1229978 Jan  4 19:12 clover.xml
-rw-r--r-- 1 81050 20059  720443 Jan  4 19:12 lcov.info
drwxr-xr-x 6 81050 20059    4096 Jan  4 19:12 lcov-report
-rw-r--r-- 1 81050 20059 4455341 Jan  4 19:12 coverage-final.json

I see references in this file to "Api.tsx" (and many others), but I don't see a reference to "Api.spec.tsx", but I have no idea whether I should expect any.

I've looked at the jest configuration in "package.json", but I don't see any obvious problems.

What else can I show here that might provide a clue?

Update:

Here is the resulting sonar-scanner command line, with some elisions:

sonar-scanner -Dsonar.typescript.node=/opt/app/bin/node -Dsonar.nodejs.executable=/opt/app/bin/node -Dsonar.host.url=http://... -Dsonar.login=... -Dsonar.password= -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info -Dsonar.typescript.lcov.reportPaths=coverage/lcov.info -Dsonar.branch.name= -Dsonar.language=js -Dsonar.projectKey=... -Dsonar.projectName=... '-Dsonar.exclusions=**/*.scss.d.ts, **/*.scss, **/*Props.ts, **/*State.ts, **/*index.ts' '-Dsonar.coverage.exclusions=**/*.spec.tsx, **/*.spec.ts, **/*.scss.d.ts, **/*.css.d.ts, **/*.scss' -Dsonar.projectVersion=1.0.0 '-Dsonar.sources=src/components/,src/api/,src/models/mappers/, src/utils/' '-Dsonar.lang.patterns.js=*/.ts,*/.tsx' -Dsonar.js.file.suffixes=.ts,.tsx -Dsonar.sourceEncoding=UTF-8 -Dsonar.tests=src '-Dsonar.test.inclusions=**/*.spec.tsx' -Dsonar.typescript.tslintconfigpath=tslint.json -Dsonar.log.level=DEBUG -Dsonar.verbose=true '-Dsonar.exec.maxBuffer=1024 * 1024'
1
I am facing the same issue. did you get any resolution for the same. Please share. in my case, when jenkin pipeline runs. it was says that it can not find the lcov.info file and shows test coverage as 0%. - Mohit Sahu
Hopefully the answer I provided helps. - David M. Karr

1 Answers

0
votes

I'd forgotten I'd asked this question. I had to go back to the code and history to see if I could remember what I did to fix it. I assume it would be what I discovered here:

https://community.sonarsource.com/t/sensor-sonarts-coverage-fails-to-match-path-with-symbolic-link/14601

In short, if file paths in the generated files include symbolic link entries, there was a bug in SonarTS that made it fail to follow symbolic links. What I did to fix this particular problem was examine my generated files to understand the pattern of what symbolic links were being utilized, and I wrote a script to post-process the lcov.info and test-report.xml file to replace paths to symbolic links with the absolute path to the non-symlinked file.