I am trying to use sonar.inclusions filter to speed up analysis of our c# projects, by limiting analysis scope to files which has changed since last version. But for some reason quality gate doesn’t include newly added files to a “New Code”, even though these files are analyzed and issues are indeed detected.
Minimal example for this bug goes like this:
Create new project in SonarQube
Set quality gate conditions to Blocker, Major, Minor, Info counts >= 0 on New Code
Analyze master branch fully - with default filters including **/*.cs
Set new code period to a specific version - previous analysis
Then add single commit touching file a.cs with some code smell, and create file b.cs with code smell also
Set sonar.inclusions setting for project to include only a.cs and b.cs
Run analysis of new commit. Actual result - quality gate detects only new code smell in a.cs as New Code, ignoring code smell in b.cs. Expected result - quality gate detects both code smells in a.cs and b.cs as New Code
versions used: SonarQube Community 8.4, sonar-scanner-msbuild-4.6.0.1930-net46
Your question motivated me to do more experiments, so I was able to find workaround for my problem.
Answering your question: Inclusion filter has nothing to do with the issue - there is no difference in behaviour with and without this filter, it still dont use issues in new file for quality gate.
And I was actually made a mistake with my case description. The difference is that new commit I mentioned in 5th step actually was made before starting analysis in 3rd step. I tried to repeat steps 1-7 as I first described it, only with commit really added to repo after first analysis, and get expected result.
Then I understood the reason might be in git commit information, used to date code changes.
And I found setting that have importance in this case: sonar.scm.disabled setting, which was initially set to false. After I set it to true and repeated steps 1-7, I got expected results, and new file was correctly used by quality gate.
It’s a bit unintuitive to me, that changes made in the same commit counts as new code and not new code at the same time. But maybe it just quirks of New Code detection algorithm which I happend to stumble upon.