we would like to utilize the standard feature of automatic assignment of the git commiter to the sonar issue. However, it doesn’t work and every issue is assigned to the default assignee user.
SonarQube Version is 6.7.6 (build 38781).
SCM is under Git (Sonar setting is set to automatically recognize it)
What we checked:
Administration -> Configuration -> SCM -> “Disable the retrieval of blame information from Source Control Manager” -> is OFF
Email addresses in the Git config and the Sonar user are matching
According users already logged in into SonarQube (was mentioned as an issue in other tickets)
Let’s back up. Your job checks out the project and runs analysis from the checkout directory? The SCM files (e.g. .git directory) are present in the directory from which analysis is run? “Blame” information is available in the SonarQube UI? E.G.
This is the root cause. You’ve said that SCM blame data suppression (TBH I didn’t remember that one, but okay) is off. There are multiple levels at which such things can be set. Please check the Scanner Context of an analysis (Project Administration > Background Tasks > [task gear menu] > Show Scanner Context) for the ultimate values of that property and sonar.scm.disabled.
I checked the scanner context of the project and " sonar.scm.disabled" is not in the list at all.
Only those properties containing the word “scm” were in the list:
SonarQube plugins:
- Git 1.8.0.1574 (scmgit)
Global properties:
- sonar.links.scm=<our url>
Settings for module: <our module>
- sonar.links.scm=
- sonar.links.scm_dev=
The setting, that I mentioned before is in the Configuration -> General Settings -> SCM UI:
You’re showing me the global-level setting, which is one of the places to check. Can you also check at the project level?
If you still come up empty there, then try running an analysis in debug mode (-Dsonar.verbose=true on the analysis command line) and re-checking the background task context.
both global and project configuration looked the same. We ran the analysis in verbose mode and found
[INFO] SCM provider for this project is: git
[22:36:22] : [Step 1/1] [INFO] 208 files to be analyzed
[22:36:22] : [Step 1/1] [INFO] 0/208 files analyzed
[22:36:22] : [Step 1/1] [WARNING] Missing blame information for the following files:
Executing git blame in the console with a file on the build server works just fine. So the information is available there.
Hence, it seems like SonarQube is actually recognizing that the SCM provider is git. It starts looking for the blame information - that is available - but it doesn’t find or recognize it.
(Also re-checked the background task context: there were still the same SCM related properties as listed above.)
I am not sure if I understand your question correctly. Our build server checks out the project each night and performs the sonar scan. This sonar project exists for multiple months, the code base exists for multiple years and is changed daily. The scan is performed each night.
For example, last night, the scan found multiple new issues, that were all assigned to the fallback user.
Can you provide the entire log please?
What is after Missing blame information for the following files:?
Does it lists all (208) project files? Are there any other message explaining why blame is missing?
Our scanner doesn’t use native git CLI, but JGit. Sometimes the behavior is slightly different, so could you also download the JGit CLI, and run the blame command again on your build server to see if the author email address is correct?
after the “Missing blame information…” it just lists the according files, no additional information.
We tried blaming using JGit and it fails with some files. We have Java and Groovy and blaming some files seems to end up in a NullPointerException while other files are fine.
Is you build agent configured to do a partial clone (shallow clone)? This is known to cause issue when computing blame. Ensure to do a full clone.
Another known problem is when using Git submodules.
Thanks for the pointers! We do not use Git submodules or shallow clones. But we moved our project out of a different repository few months ago and manipulated the Git history when doing so. It works fine with (common) Git but may cause the problems with JGit? Is there anything we can do to make it work with Sonar/JGit?
Since the Sonar project is existing (after moving out of the project out of the former repository) not a single issue was correctly assigned.
I tried blaming the files that had new issues this night using JGit and each one gave me a NullPointerException. I will open a ticket with JGit and link it here.
Thank you a lot, Julien and Ann, for your help so far!
