We have been using Sonarqube for about the last 2 months on our TFS 2017 server. Overall it has been very helpful, but a few weeks ago one of our builds started failing due to Sonarqube returning a 401 error (Unauthorised).
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Failed to request and parse 'http://sonarqube.local:9000/api/settings/values?component=MYPROJECTNAME%3Amaster': The remote server returned an error: (401) Unauthorized.
2017-10-12T15:11:19.7921253Z ##[error]16:11:19.729 Could not authorize while connecting to the SonarQube server. Check your credentials and try again.
The curious thing about this is that other builds from other projects are working absolutely fine, using the same API token. I've even created a new Sonarqube endpoint in the failing project, then again in a known good project - again using the same API key on both - only for the same thing to happen. One fails with the above error, the other is fine.
I thought this might have been a security/permission option within sonarqube itself, so I tried creating a completely new sonarqube project but again - one TFS project fails, while another succeeds when both are pointing to this new project.
I suspect this issue stems from the TFS project's security settings, but after comparing a good project with the bad project, nothing is jumping out at me as to what the cause may be - they seem to be set up the same. I enabled debugging on both a good build and the bad build and compared the outputs. As far as I can tell, the only real difference between the two is that the "Failing" build is picking up a sonar.password from somewhere whereas the good build is not:
Good:
2017-10-12T15:13:07.1067146Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]
2017-10-12T15:13:07.2785974Z ##[debug] arguments = /c ""Y:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe" begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.7" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master""
Bad:
2017-10-12T15:11:19.5733714Z ##[debug]Processed: ##vso[task.setvariable variable=MSBuild.SonarQube.ServerPassword;]********
2017-10-12T15:11:19.5733714Z ##[debug] Path: Z:\2017_agent_work_tasks\SonarQubeScannerMsBuildBegin_15b84ca1-b62f-4a2a-a403-89b77a063157\3.0.2\SonarQubeScannerMsBuild\MSBuild.SonarQube.Runner.exe 2017-10-12T15:11:19.5733714Z ##[debug] Arguments: begin /k:"MYPROJECTNAME" /n:"MYPROJECTNAME" /v:"20171012.3" /d:sonar.host.url="http://sonarqube.local:9000/" /d:sonar.login=******** /d:sonar.password=******** /d:sonar.cs.vscoveragexml.reportsPaths="***.coveragexml" /d:sonar.branch="master"
(Note: Although the good/bad ran on different build agents in this instance, the agents are identical and I've confirmed that "good" projects work on all of our agents while the "bad" project fails with the same result on all agents).
However, I have no idea where it's getting this password from - there is no sonar.properties file in the repository. To be absolutely sure, I cloned the repository for the failing TFS project, pushed it into a repository in a working TFS project, replicated the build and it works.
I've checked the logs from Sonarqube itself and they are less than helpful
What could I have missed?
TFS 2017 is 15.117.26714.0
Sonarqube is 6.5.0.27846
Sonarqube task version is 3.0.2
EDIT: I have managed to get a temporary workaround for this by editing the build task to NOT insert sonar.password into the command line and this works. That does prove that the root issue is the task pulling this mystery password from "somewhere" but I'm still at a loss as to where it would be picking it up. I cannot find much information on what sets MSBuild.SonarQube.ServerPassword
