When I run the scan on a Centos build agent, only 1 file is included in the code coverage, but running the same against the exact same branch locally results in 39 files being included.
I am running the Sonar-Scanner on a JavaScript repository.
The exact same version of the scanner is being used on the Centos build agent as it being run by myself locally.
I am running the scanner locally on my mac (same version of the scanner: SonarScanner 5.0.1.3006)
The scan output is identical (within reason) except for one detail; when running locally (against the same branch of the same repo) I get 48 files found and processed by the SCM Publisher, when running on the build agent, I get only 1.
This is only code coverage - all other scan results in SonarCloud are identical - same results, same number of files, etc.
The exact same parameters are passed to the sonar scanner in both instances.
The lcov file generatred by both is identical.
The only difference is that when running from the build agent, I get only 1 file showing in code coverage in SonarCloud.
Running the same locally shows me 39 files in the code coverage.
I can find no other differences at all (same versions of git, node, npm, etc).
Why is there a difference when running on my build agent and how can I ensure all files are included in the code coverage, no matter where it is run?
I must disagree. There are lots of differences between the two logs (not least the thousands of lines of warnings about missing files in the build agent log). I won’t catalog them all. Here’s one that’s important:
INFO: Sensor JavaScript/TypeScript Coverage [javascript]
INFO: No LCOV files were found using /home/jenkins/agent/workspace/AB-Auto-Scan/coverage/lcov.info
WARN: No coverage information will be saved because all LCOV files cannot be found.
INFO: Sensor JavaScript/TypeScript Coverage [javascript] (done) | time=1274ms
The coverage report is found in the local analysis, but not on the build agent. It’s not clear to me where the coverage for this one is coming from:
But let’s talk about that 1.
Local
INFO: 509 files indexed
INFO: 63826 files ignored because of inclusion/exclusion patterns
INFO: 5179 files ignored because of scm ignore settings
Build agent:
INFO: 509 files indexed
INFO: 63214 files ignored because of inclusion/exclusion patterns
INFO: 4717 files ignored because of scm ignore settings
These indicate a difference in the SCM settings. Why does that matter if they both found the same number (509) of files to analyze? Because both logs indicate this is a short-lived branch
And in short-lived branches, only new code is reported on. That’s why this bit at the end, which you’ve already pointed out, is important:
Local
INFO: SCM Publisher SCM provider for this project is: git
INFO: SCM Publisher 48 source files to be analyzed
INFO: SCM Publisher 48/48 source files have been analyzed (done) | time=319ms
Build agent
INFO: SCM Publisher SCM provider for this project is: git
INFO: SCM Publisher 1 source file to be analyzed
INFO: SCM Publisher 1/1 source file have been analyzed (done) | time=112ms
The only file on the build agent eligible to be reported on in the short-lived branch analysis is (presumably) the one file that shows up as covered.
I had noticed all the warnings and was looking into that, but I did not see that the lcov file was not being found - I will focus on that ad let you know what I find!
Hello Ann,
I thought those results were a bit suspicious.
That was the wrong build agent analysis log - I was playing with different paths to see if it helped.
Here is the log file I meant to send - it does have the lcov file and is being analysed. buildagent_sonar_scan.txt (16.5 KB)
No file warnings anymore - the only major difference is the number of files found by the SCM Publisher.
By the way, this is being run on the same branch of the same repo, so why would there be any difference in files? there are no changes in the repo.
I would expect that if the code in the repo is the same, the results should be as well.
I can’t understand why the SCM files are different when run locally against on the remote.
For short-lived branches, the new code consists of all those files which have been modified or added relative to the target branch. Modified files are determined by comparing checksums between the sonar.branch.target branch and the short-lived branch to be analyzed.
Admittedly, I’m fuzzy on the details of how new code is detected for short-lived branches (particularly since the capabilities are bit different between SonarQube and SonarCloud) but I believe the question here is what was available about the target branch in the local Git repository.
It seems to me that the issue is the number of files found by the SCM publisher.
The scan is being run on the same branch with no changes, so I would expect the number of files being found to be the same.
It seems that everything else about the scan is identical, but for some reason, the number of files found by the SCM for scanning is different.
I can’t explain why there would be any differences - we are simply running a git checkout on the branch.
This is always on an ephemeral agent, so the repo is being cloned fresh each time.
Any help on this would be appreciated - it is currently a blocker for me.
I am getting the same results now when running locally - clearly had some bad juju in the local repo I was using even when performing the full git checkout.
With that mystery cleared up, I am very happy that the results from both scans are now identical.
This ticket can of course be closed.
Thank you again for all your efforts on this, I really do appreciate it!