sonar:
image:
name: sonarsource/sonar-scanner-cli:4.7
entrypoint: [""]
stage: quality
needs:
- job: Test
artifacts: true
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" # Defines the location of the analysis task cache
GIT_DEPTH: "0" # Tells git to fetch all the branches of the project, required by the analysis task
cache:
key: "${CI_JOB_NAME}"
paths:
- .sonar/cache
script:
- sonar-scanner
only:
refs: *build_and_publish
The job that this one depends is “Test” and it produces a coverage/lcov.info file that is passed to the Sonar job as an artifact
You can find here the content of the artifact passed to the Sonar Job. artifacts.zip (182.1 KB)
When I looked at the logs, I did saw a warning but I don’t know if that’s the root cause…
INFO: Analysing [/builds/GDbogi_A/3/groupemutuel.io/plateforme-front-office/assures/gmapp/coverage/lcov.info]
WARN: Could not resolve 50 file paths in [/builds/GDbogi_A/3/groupemutuel.io/plateforme-front-office/assures/gmapp/coverage/lcov.info]
WARN: First unresolved path: /builds/GDbogi_A/1/groupemutuel.io/plateforme-front-office/assures/gmapp/src/modules/@docs/producer/store/actions.js (Run in DEBUG mode to get full list of unresolved paths)
INFO: Sensor JavaScript/TypeScript Coverage [javascript] (done) | time=17ms
When I look at my repository I can indeed find the expected file…
The issue comes from the fact that absolute paths are used in the coverage report that don’t match the file paths in the environment the scanner is running.
You can try and see if your coverage reporter supports paths relative to the root of your project
Some users find it possible to post-process the coverage report using sed to fix the paths
You could run your tests in the same environment as you run analysis
Anyway, thanks for your reply.
I tried the third option that you proposed → run the analysis on the same environment as I execute the tests
Unfortunately, I still have the same warning with path that are not found…
INFO: Analysing [/builds/GDbogi_A/0/groupemutuel.io/plateforme-front-office/assures/gmapp/coverage/lcov.info]
WARN: Could not resolve 1 file paths in [/builds/GDbogi_A/0/groupemutuel.io/plateforme-front-office/assures/gmapp/coverage/lcov.info]
WARN: First unresolved path: /builds/GDbogi_A/0/groupemutuel.io/plateforme-front-office/assures/gmapp/src/modules/@tech/pdf/fixtures.js (Run in DEBUG mode to get full list of unresolved paths)
INFO: Sensor JavaScript/TypeScript Coverage [javascript] (done) | time=27ms
And what is more wired it is that now the path seems the same for the lcov.info file and the file Sonar tries to read (/builds/GDbogi_A/0/groupemutuel.io/plateforme-front-office/assures/gmapp)
Here is my gitlab-ci’s job up to date with the modification:
Test & Quality:
image: $NODE_IMAGE
stage: build
variables:
SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar" # Defines the location of the analysis task cache
GIT_DEPTH: "0" # Tells git to fetch all the branches of the project, required by the analysis task
script:
- |
# printing the job status
echo "**********************************************"
echo "*************** yarn install *****************"
echo "**********************************************"
- yarn --frozen-lockfile --network-timeout 300000
- |
# printing the job status
echo "---------- yarn install successfull ----------"
echo "**********************************************"
echo "*************** Quality tasks ****************"
echo "**********************************************"
- yarn run lint && yarn test --ci
- yarn global add sonarqube-scanner
- yarn sonar
- |
# printing the job status
echo "--------- Quality tasks successfull ----------"
only:
refs: *build_and_publish
Let me suggest you bump up to DEBUG level logging (sonar.verbose=true) in your current configuration and upload the logs. A recent copy of the coverage report (as you provided earlier) would also be useful to compare.
I am sorry to open a new ticket but the one that I opened the 15th of March didn’t get any answer… I have been in touch with @Colin that asked my some question that I did answer but never heard him back.
I’ve just clicked the link to see the logs Colin requested & I was asked to accept a ToS to get to them. I suspect that’s where he stopped. It’s certainly where I stopped.
Please copy/paste your logs into this thread & code-format them.
I had to use WeTransfert because my log’s file was too big…
I just gave a new try today and here are the logs for the Sonar part.
As @Colin asked, you’ll find in the attachment the coverage folder’s content in the archive named artifacts.zip
Ok that’s certainly because I run the tests on a specific job and the analysis on a subsequent job in Gitlab…
I could merge those 2 jobs but I didn’t want to at the begining… This is because I’ll use a nodeJS specific image for the build and your sonarsource/sonar-scanner-cli:4.7 image for Sonar analysis…
One thing you could do is normalize the paths in the report to be relative to project root. That ought to be both automatable and readily understood by analysis…