Incremental Pull Request analysis cache gets zero hits - Sonar scanner for msbuild

SonarQube Server / Community Build
, , , ,
1

SonarQube Server Data Center Edition v2025.1.1
SonarScanner for MSBuild 10.1.2
Scanner is run by a Jenkins agent on a Windows Server
Plugin csharpenterprise, version 10.4.1.110446

My goal is to reduce SQ scanning time during pull requests on a repo with 10k+ files. There is a concept of Incremental Pull Request analysis which should work for C# as stated in the documentation:

This is what I have tried:

1. Run a scan for the master branch to build the analysis cache

The logs are from processing the small (~100 files) repository. Problem is analogous to the repo with 10k+ files.
Excerpts from log file:

Processing analysis cache
Incremental PR analysis: Base branch parameter was not provided.
Cache data is empty. A full analysis will be performed.

MSBuild version 17.11.2+c078802d4 for .NET Framework
c:\workspace\repo\project\aaa.cs(372,17): warning S125: Remove this commented out code. (https://rules.sonarsource.com/csharp/RSPEC-125) [c:\workspace\repo\project\project-file.csproj]

Dumping content of sonar-project.properties
-------------------------------------------
B05329E8-C28B-48E8-1234-ADF5154BB417.sonar.sources=\
"c:\\workspace\\repo\\project\\aaa.cs",\

Calling the SonarScanner CLI...
INFO: Analyzing on SonarQube server 2025.1.1.104738
INFO: Default locale: "en_US", source code encoding: "windows-1252" (analysis is platform dependent)

INFO: Indexing files of module 'project'
DEBUG: 'project/aaa.cs' generated metadata with charset 'UTF-8'
DEBUG: 'project/aaa.cs' indexed with language 'cs'

DEBUG: Processing Roslyn report: 
DEBUG: Adding normal issue S125: C:\workspace\repo\project\aaa.cs

DEBUG: Detection of duplications for C:/workspace/repo/project/aaa.cs

INFO: Sensor C# File Caching Sensor [csharpenterprise]
DEBUG: Incremental PR analysis: Preparing to upload file hashes.
DEBUG: Incremental PR analysis: Adding hash for '/C:/workspace/repo/project/aaa.cs' to the cache.
DEBUG: Incremental PR analysis: Adding hash for '/C:/workspace/repo/project/only-file-that-will-be-changed-in-pull-request.cs' to the cache.

2. Run a scan for the PR branch to potentially use the analysis cache

Pull request has changes in one file: C:\workspace\repo\project\only-file-that-will-be-changed-in-pull-request.cs.cs

Cache is downloaded:

Processing analysis cache
Downloading cache. Project key: project-key, branch: master.
Downloading from https://sonarqube-server-address/api/analysis_cache/get?project=project-key&branch=master...
Response received from https://sonarqube-server-address/api/analysis_cache/get?project=project-key&branch=master...

But gets zero hits:

Incremental PR analysis: 0 files out of 68 are unchanged.

I this PR I would expect reduced scanning time and message “Incremental PR analysis: 67 files out of 68 are unchanged” (if I understand this properly).

What can be noticed is that in the downloaded cache file paths have forward slashes (/C:/workspace/repo/project/aaa.cs) whereas in most cases in the log file backslashes are used (it is not consistent in the log file).

What am I missing here?
Maybe the Sonar scanner has a bug and can’t handle these paths?
Or maybe is it a file encoding problem?

I would appreciate any help.

3

Hello @MarcinJ!

Could you please share with us the verbose logs of your analysis (begin and end step)?
You’ll need to add /d:"sonar.verbose=true" to the begin command.

We’ll also need the 3 commands that you use for your analysis (begin, build and end).

Thanks!

4

Based on the received tips and experiments, I managed to get a working cache. The path to sonar.projectBaseDir was crucial. It turned out that the case of the drive letter doesn’t matter, but in the path to the working directory where the scanner was launched, the characters must be lowercase (even though uppercase letters are also used in the file system). From that point on, the rest of the path to the source files can be written with both uppercase and lowercase letters – as they appear in the file system.

Example, let’s assume:

File system path to the working directory where sonar-scanner will be launched:
C:\Folder1\folder2\Folder3\workspace

File system path to the cloned repo:
C:\Folder1\folder2\Folder3\workspace\RepoFolder

The ‘sonar.projectBaseDir’ parameter where the cache didn’t work:
C:\Folder1\folder2\Folder3\workspace\RepoFolder

The ‘sonar.projectBaseDir’ parameter where the cache worked:
C:\folder1\folder2\folder3\workspace\RepoFolder
Alternatively:
c:\folder1\folder2\folder3\workspace\RepoFolder

I hope this helps someone before the SonarQube team investigates, standardizes, and describes the issues of paths and PR cache.

6

Hi @MarcinJ,

Thank you for reporting this case. We’ll fix this unintended behavior in the next release of the .NET analyzers 10.13.

9

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.