SonarQube Errors on TFS Gated Check-in Builds

tfs
sonarqube

(spy008) #1

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

These are the versions we are currently on:

  • SonarQube: 5.6.7
  • Sonar Analyzer csharp version: 6.4.1.3596
  • SonarScanner for MSBuild 4.3.1
  • MSBuild 14.0
  • Visual Studio 2015
  • TFS 2017 Update 2 (on-premise)
  • SonarQube Extension 4.2.0
  • Java Runtime 8 Update 144

(Andrew James) #2

Hi,

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.

AJ


(spy008) #3

Hi AJ,

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?

Thanks.


(Andrew James) #4

As far as I know the only easy way to get rid of the messages currently would be to turn off the SCM annotation altogether (sonar.scm.enabled=false).

I haven’t tried this approach though, and it depends on what your overall process is and whether you need SCM information in SonarQube.

Cheers,
AJ


(spy008) #5

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.


(Andrew James) #6

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.


(spy008) #7

I don’t think I ever set sonar.scm.enabled to false explicitly. Let me try and get back here. Thanks!


(spy008) #8

After trying different combinations, this is what I ended having:

#sonar.scm.enabled=false
sonar.scm.provider=tfvc
#sonar.tfvc.collectionuri=http://mytfs:8080/tfs/mycollection

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!


(spy008) #9

I celebrated too early. I’m still getting the “Unable to TFS annotate…”, and “WARN: Missing blame information…" messages. :frowning: