SonarQube error when executing blame for file
Asked Answered
C

2

12

I recently upgraded from SonarQube 5.1.2 to SonarQube 5.6. Now I'm getting an IllegalStateException "Error when executing blame for file". This happens building with my ant scripts in both Eclipse and Jenkins. In Jenkins the error is more complete, indicating SVNAuthenticationException E170001: Negotiate authentication failed: 'No valid credentials provided'.

Valid credentials are present in SonarQube Administration -> General Settings -> SCM -> SVN. They are the same credentials I was using in 5.1.2 and the blame functionality worked without error and assigned issues to the various developers. Also my build scripts populate sonar.svn.username and sonar.svn.password.secured with the same credentials.

In 5.1.2 I was using the sonar-issue-assign-plugin. I see that's deprecated now and in fact SonarQube 5.6 won't launch successfully if that plugin is present. Unfortunately whatever has taken its place isn't working for me.

I've looked at answers to questions with the same error here and here.

Edit: I'm still stuck on this one. I re-entered the credentials in SonarQube Administration > Generate Settings > SCM > SVN and restarted the server. Same result. Here is the last part of the exception stack trace:

Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: E170001: Negotiate authentication failed: 'No valid credentials provided' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication$1.run(DefaultHTTPNegotiateAuthentication.java:175) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication$1.run(DefaultHTTPNegotiateAuthentication.java:166) at org.tmatesoft.svn.core.internal.io.dav.http.DefaultHTTPNegotiateAuthentication.authenticate(DefaultHTTPNegotiateAuthentication.java:221) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:477) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:398) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:386) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:863) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:699) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:118) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1049) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.hasCapability(DAVRepository.java:877) at org.tmatesoft.svn.core.io.SVNRepository.assertServerIsMergeInfoCapable(SVNRepository.java:787) at org.tmatesoft.svn.core.io.SVNRepository.getFileRevisions(SVNRepository.java:756) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run(SvnRemoteAnnotate.java:111) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteAnnotate.run(SvnRemoteAnnotate.java:35) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNLogClient.doAnnotate(SVNLogClient.java:295) at org.sonar.plugins.scm.svn.SvnBlameCommand.blame(SvnBlameCommand.java:100) ... 64 more

Edit 2: I've run this as an Ant Task using the sonarqube-ant-task-2.5.jar and I've run it as a separate build step in Jenkins using the SonarQube plugin (version 2.4.4) with the same result. I'm still at a loss as to why it's not finding my SVN credentials when trying to assign blame.

Centralize answered 25/1, 2017 at 17:4 Comment(1)
C
8

I'm going to answer my own question as I've found a solution that works. It appears to be an issue with SVNKit where my SVN server is using NTLM or Negotiate authentication and the tmatesoft svn code called by the SonarQube plugin doesn't support that in my environment.

Adding the following to the Jenkins host JVM options resolves the issue:

-Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM

Solution found here.

This works for calling Sonar from Ant by adding it to JVM Options when invoking the ant script, and it also works for the Jenkins build task Execute SonarQube Scanner when added to JVM Options.

Centralize answered 30/1, 2017 at 18:33 Comment(2)
Thank you. Had the same problem. Solved it for me too.Pensive
Thank you, this is what I needed. I found the fallback to NTLM isn't working,so I had to move that to the front in my case. i.e. -Dsvnkit.http.methods=NTLM,Basic,Digest,Negotiate There is a bug report here issues.tmatesoft.com/issue/SVNKIT-502Blandishment
F
2

As another SO user recomends, if you do not need SonarQube's SCM sensor, you can disable it and avoid those errors. Just go to Administration > Configuration > General Settings > SCM > Disable SCM sensor

enter image description here

Flashcube answered 8/6, 2022 at 11:59 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.