We have TFS vNext builds setup as Gated check-in builds, meaning code changes are checked in only if the builds are successful. This is causing SonarQube to throw the following errors and warnings when running a code analysis.
10:44:08.325 ERROR: Unable to TFS annotate the following file which line 10 has not yet been checked-in (LOCAL): C:/BuildAgents/Agent1/_work/46/s/DotNet/MyProject/File1.cs
10:44:11.746 ERROR: Unable to TFS annotate the following file which line 547 has not yet been checked-in (LOCAL): C:/BuildAgents/Agent1/_work/46/s/DotNet/MyProject/File2.cs
10:44:11.762 WARN: Missing blame information for the following files:
10:44:11.762 WARN: * C:/BuildAgents/Agent1/_work/46/s/DotNet/MyProject/File1.cs 10:44:11.762 WARN: * C:/BuildAgents/Agent1/_work/46/s/DotNet/MyProject/File2.cs
10:44:11.762 WARN: This may lead to missing/broken features in SonarQube
I am passing the below properties. Am I required to pass value for “sonar.tfvc.username” and “sonar.tfvc.password.secured” or would it know to use Windows authentication?
sonar.scm.enabled=true
sonar.scm.provider=tfvc
sonar.tfvc.collectionuri=http://mytfs:8080/tfs/mycollection
I don’t think you need to provide the user name and password. We have a similar configuration and don’t need those.
The errors you are getting are because you’re checking in new code and that code isn’t committed to source control until the gated build finishes, so at the point the analysis is run there isn’t any source control annotation information to retrieve for it. I don’t think the scm annotation can work in this situation because it always tries to retrieve information about code that has already been committed to source control. It’s also possible that the build could still fail after the analysis, so the code might not get committed at all.
What we do is run our Gated builds without the SonarQube analysis steps (just checking that code compiles and passes tests), and have a separate continuous integration build triggered (in batches) which runs the analysis when the changeset is committed.
I understand what you are saying and it makes sense. However, our requirement is to only allow code to be committed if it had compiled and passed tests including SonarQube code analysis. Therefore, the build steps and the SonarQube steps have to be part of the same build definition. The errors are not preventing us from checking in code, but the builds do not look as “clean” with all the errors and warnings. Is there any way to suppress the errors and warnings at all?
The reason I set “sonar.scm.enabled=true” in the first place is to get rid of these warnings:
09:16:41.816 WARN: SCM provider autodetection failed. No SCM provider claims to support this project. Please use sonar.scm.provider to define SCM of your project.
Do you still get those if you set sonar.scm.enabled=false explicitly?
I know we had those warnings, and we got rid of them by adding the sonar.scm.provider=tfvc line. I thought that it wouldn’t be looking for an SCM provider at all if sonar.scm.enabled is set to false though. If it is then I don’t know how to work around that, sorry.
Like you said, by just having the sonar.scm.provider=tfvc line, I no longer see the “WARN: SCM provider autodetection failed”, “Unable to TFS annotate…”, and “WARN: Missing blame information…” messages. Thanks so much for the help!
