By versions, I meant SonarQube, scanner, analyzers, …
Also, what’s your analysis command line, and what plugins (with versions, please) are in your instance. The Issue summary at the end of your analysis log is highly suspicious. IIRC that functionality went away quite a while ago.
As for the summary you are seeing, it is from our custom script that downloads the JSON report from Sonar and extracts info from it. We have the same number of issues when we go to the Web interface so I guess that is not a problem of us fetching the incorrect data.
Our analysis command line is very classic: Build wrapper of our build then the scanner.
So we are launching the scan of the src/ directory from the scripts/ dir using config/sonar/sonar-project.properties as a config.
# The default configuration file for SonarQube
# Sonar wrapper output dir
Here is our sonar-project.properties:
# must be unique in a given SonarQube instance
# Path is relative to the sonar-project.properties file. Replace "\" by "/" on Windows.
# This property is optional if sonar.modules is set.
# Encoding of the source code. Default is default system encoding
# Analyzes only the specified files
I doubt this is related to the bug you mentioned because I can see in the “code” tab that only changed files are present. The problem is that it is showing all the bugs present in files, not only the ones introduced in the changed lines of the short lived branch.
Short lived branches don’t hide issues depending whether a line is considered to be new or changed.
What SonarQube does is it compares the issues found in the branch (in changed files) against the issues known in its target branch, and only shows the issues that are new.
Is the old issue present in the branch targeted by this SLB?
I think I might have a scenario that spots the issue date difference between master branch and short lived branches. I recall that short lived branch issue dates are older that the ones of master for the same issues.
Here is what we did and what I think caused the problem:
Create a project and perform a scan on master -> this will spot issues
some days later delete the project
recreate the project with the same name and perform a scan on master again -> this will spot the same issues but with a more recent date
perform a scan on a short lived branch
-> the short lived branch will show issues present in master but with the first date instead of the second, while master shows them with the second date.
Issues should be backdated on initial project analysis. We’ve made some advances in backdating since 7.3 (altho particularly in this area, to be honest). We’ve also made big improvements in branches. You really should upgrade.
As a member of the development team, I’m always going to want to urge you to the latest/greatest. However, I don’t think it’s necessary in this case. The 7.6 E.T.A. is next Monday but there’s nothing related to branches in it.