"Sensor SonarTS Coverage" fails to match path with symbolic link

SonarQube
1

Versions used

SonarQube Version 7.5 (build 20543), SonarScanner 2.6 and/or 3.0.3.778

Setup

On my system /applis is a symbolic link referencing /app/list.
-Dsonar.projectBaseDir points to /applis/jbreda/.jenkins/workspaces/ionic3/master/

Error observed

INFO: Sensor SonarTS Coverage [typescript]
INFO: Analysing [/applis/jbreda/.jenkins/workspaces/ionic3/master/coverage/lcov.info]
INFO: Could not resolve 237 file paths in [/applis/jbreda/.jenkins/workspaces/ionic3/master/coverage/lcov.info], first unresolved path: /app/list/applis/jbreda/.jenkins/workspaces/ionic3/master/src/app/app-back-button.ts
INFO: Sensor SonarTS Coverage [typescript] (done) | time=21ms

Workaround

Force -Dsonar.projectBaseDir to not use the symbolic link /applis

Tests done

On my system (Linux), I checked :

  • that the file /app/list/applis/jbreda/.jenkins/workspaces/ionic3/master/src/app/app-back-button.ts exists
  • that I am the owner of the file /app/list/applis/jbreda/.jenkins/workspaces/ionic3/master/src/app/app-back-button.ts (with correct rights)
  • if I change the filepath in lcov.info to /applis/jbreda/.jenkins/workspaces/ionic3/master/src/app/app-back-button.ts, then :
    – the path is resolved
    – the count of unresolved path decreases by one
    – the next path starting with /app/list in lcov.info appears in the log as the new “first unresolved path”

My last test makes me think that sonarTS doesn’t compare “real path” (canonical path ?) of the current file with the real path of all of the registered files.

3

Hello,

Do you still have the problem with recent versions of SonarQube? With 8.2 for example?

Thanks

4

I’d like to resurrect this thread. I’m running into this problem again, because my workaround is fragile. We still have this problem with SonarQube 7.9.2.

To be clear, the basic problem that I can see is that SonarTS doesn’t understand symbolic links. If any part of the file path crosses a symlink, SonarTS will not be able to find the file.

I have implemented a workaround that processes the entire lcov.info file, replacing the “SF:…” lines, where the path after the colon is the “real path” of the file. This works, but it’s annoying to have to do this, especially when the one-liner to make this modification in a Jenkins build script is very obtuse, not just for bash syntax, but also in order to get proper escaping of special characters in multiple contexts.

7

hello @David_Karr ,

are you still having this issue? Did you try to update to the latest LTS?