SonarQube Version 7.5 (build 20543), SonarScanner 2.6 and/or 126.96.36.1998
On my system /applis is a symbolic link referencing /app/list.
-Dsonar.projectBaseDir points to /applis/jbreda/.jenkins/workspaces/ionic3/master/
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
Force -Dsonar.projectBaseDir to not use the symbolic link /applis
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.