Error in SonarQube when launching svn blame
Asked Answered
B

6

16

I recently upgraded my SonarQube server from 4.5.2 to 5.0.1, then to 5.1 (see edit below).

Suddenly, the analysis of a multi-module Maven project failed with the following error :

[INFO] [12:02:05.045] Sensor SCM Sensor...
[INFO] [12:02:05.169] SCM provider for this project is: svn
[INFO] [12:02:05.169] Retrieve SCM blame information...
[INFO] [12:02:05.185] 650 files to be analyzed
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] myproject ......................................... FAILURE [3:21.165s]
[INFO] module1 ........................................... SKIPPED
[INFO] module2 ........................................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:42.429s
[INFO] Finished at: Thu Feb 26 11:30:01 CET 2015
[INFO] Final Memory: 73M/2020M
[DEBUG] [11:30:01.789] Executing: svn blame --xml --non-interactive -x -w src/main/java/MyClass.java
[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli) on project myproject: java.io.IOException: Cannot run progra
m "svn" (in directory "C:\somedirectory\module1"): CreateProcess error=2, The system cannot find the file specified
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: java.io.IOException: Cannot run program "svn" (in directory "C:\somedirectory\module1"): CreateProcess error=2, The system cannot find the file specified
        at org.codehaus.mojo.sonar.bootstrap.ExceptionHandling.handle(ExceptionHandling.java:41)
        at org.codehaus.mojo.sonar.bootstrap.RunnerBootstraper.execute(RunnerBootstraper.java:139)
        at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:138)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
        ... 19 more

Somehow, the command svn did not find the file src/main/java/MyClass.java in directory C:\somedirectory\module1, although that file is definitely there. If I copy-paste the command SonarQube is trying to execute in a command prompt svn blame --xml --non-interactive -x -w src/main/java/MyClass.java inside directory C:\somedirectory\module1 then the command is working fine.

svn command is correctly on the PATH, as can be seen in the "Library Path" field on "System Info" page in SonarQube server. SonarQube server is hosted on the same server where mvn sonar:sonar was executed (Windows Server 2008 R2).

svn is being launched by SonarQube to retrieve blame history. As I understand, there were some changes made in SonarQube 5.0 concerning SCM support (change to built-in). My workaround for now is to disable the SCM sensor in SonarQube (using -Dsonar.scm.disabled=true or directly in the SonarQube server, under "Settings > General Settings > SCM").

This is not related to this question since I only encountered that behaviour when I upgraded to SonarQube 5.0.1.

JRE used : 1.7.0_51 (64 bits)

EDIT :

After an upgrade to SonarQube 5.1, the error is still here but the message is different and more clear. I have reinstalled a SVN client (TortoiseSVN) and restarted both Jenkins and SonarQube but the error stays:

SCM provider was set to "svn" but no SCM provider found for this key. No SCM provider installed

[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli) on project bombardier: SCM provider was set to "svn" but no SCM provider found for this key. No SCM provider installed -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli) on project bombardier: SCM provider was set to "svn" but no SCM provider found for this key. No SCM provider installed
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoExecutionException: SCM provider was set to "svn" but no SCM provider found for this key. No SCM provider installed
    at org.codehaus.mojo.sonar.bootstrap.ExceptionHandling.handle(ExceptionHandling.java:41)
    at org.codehaus.mojo.sonar.bootstrap.RunnerBootstraper.execute(RunnerBootstraper.java:139)
    at org.codehaus.mojo.sonar.SonarMojo.execute(SonarMojo.java:138)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
    ... 19 more
Caused by: java.lang.IllegalArgumentException: SCM provider was set to "svn" but no SCM provider found for this key. No SCM provider installed
    at org.sonar.batch.scm.ScmConfiguration.setProviderIfSupported(ScmConfiguration.java:123)
    at org.sonar.batch.scm.ScmConfiguration.considerOldScmUrl(ScmConfiguration.java:133)
    at org.sonar.batch.scm.ScmConfiguration.start(ScmConfiguration.java:109)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.invokeMethod(ReflectionLifecycleStrategy.java:110)
    at org.picocontainer.lifecycle.ReflectionLifecycleStrategy.start(ReflectionLifecycleStrategy.java:89)
    at org.picocontainer.injectors.AbstractInjectionFactory$LifecycleAdapter.start(AbstractInjectionFactory.java:84)
    at org.picocontainer.behaviors.AbstractBehavior.start(AbstractBehavior.java:169)
    at org.picocontainer.behaviors.Stored$RealComponentLifecycle.start(Stored.java:132)
    at org.picocontainer.behaviors.Stored.start(Stored.java:110)
    at org.picocontainer.DefaultPicoContainer.potentiallyStartAdapter(DefaultPicoContainer.java:1015)
    at org.picocontainer.DefaultPicoContainer.startAdapters(DefaultPicoContainer.java:1008)
    at org.picocontainer.DefaultPicoContainer.start(DefaultPicoContainer.java:766)
    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:91)
    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
    at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:57)
    at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:45)
    at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:135)
    at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92)
    at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77)
    at org.sonar.batch.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:158)
    at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95)
    at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
    at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:48)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87)
    at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
    at java.security.AccessController.doPrivileged(Native Method)
    at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
    at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
    at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
    at org.sonar.runner.api.Runner.execute(Runner.java:100)
    at org.codehaus.mojo.sonar.bootstrap.RunnerBootstraper.execute(RunnerBootstraper.java:135)
    ... 22 more
Bruise answered 26/2, 2015 at 11:6 Comment(2)
error is very complex you should select some piece of themCurvy
@HamitYıldırım I disagree, all the stacktrace might be relevant for someone to debug the issue. And it is not that long.Bruise
S
8

I experienced same issue after installing SonarQube 5.1, go to Update Center:

http://your_domain:port/updatecenter/available

search for the "SVN", click "Install"

https://docs.sonarqube.org/display/PLUG/SVN+Plugin

Something like this will appear:

SonarQube needs to be restarted in order to install the following plugins: sonar-scm-svn-plugin-1.0.jar

Restart your SonarQube.

Sayed answered 3/4, 2015 at 8:1 Comment(2)
Yes, that nailed it! I did not notice there was a new SVN plugin. This should be definitely mentioned in the upgrade notes.Bruise
I can confirm the same for git. We moved our Sonarqube from 4.5 to 6.4 on a new server. The old server had a git installation. By adding the git-plugin link I resolved the issue.Blinders
M
38

use the below command which will disable the svn related issues

-Dsonar.scm.disabled=True

this will disable the svn

Mono answered 4/3, 2015 at 16:32 Comment(2)
I already did that. I disabled the SCM sensor on SonarQube server and it works without it. But I would like it to work with the SCM sensor.Bruise
"mvn sonar:sonar -Dsonar.scm.disabled=True" . Worked for me. ThanksQuagmire
S
8

I experienced same issue after installing SonarQube 5.1, go to Update Center:

http://your_domain:port/updatecenter/available

search for the "SVN", click "Install"

https://docs.sonarqube.org/display/PLUG/SVN+Plugin

Something like this will appear:

SonarQube needs to be restarted in order to install the following plugins: sonar-scm-svn-plugin-1.0.jar

Restart your SonarQube.

Sayed answered 3/4, 2015 at 8:1 Comment(2)
Yes, that nailed it! I did not notice there was a new SVN plugin. This should be definitely mentioned in the upgrade notes.Bruise
I can confirm the same for git. We moved our Sonarqube from 4.5 to 6.4 on a new server. The old server had a git installation. By adding the git-plugin link I resolved the issue.Blinders
M
8

This issue can be solve by two way,
1. by setting the sonar.properties -Dsonar.scm.disabled=True, this is valid only for sonarrunner.bat sonar analysis,
2. If your doing using any other type analysis then login with admin default admin is admin/admin(username/password).http://yourDomin:port/settings/index(e.g http://localhost:9000/settings/index) then in category select the scm and disable the scm sensor set as true.
3.or else u can add the svn plugin to the sonar http://your_domain:port/updatecenter/available after login as admin(admin/admin), search for the available plugin and select the svn and install it..

Macaluso answered 2/9, 2015 at 20:53 Comment(0)
R
1

I had this problem and it was caused by not having an active installation of SVN on the build machine that was running the sonar analysis. It doesn't matter what the sonar box has installed. It's the build agent which needs to do the SVN blame.

I was using CentOS. The magic was

sudo yum install svn

The final trick was to make sure that the build machine was using the same version of SVN for checkout as the version I installed. If the build machine was natively using a different version you may have to make sure it cleans the whole workspace before its next check out too.

Finally, don't forget that Sonar needs your SVN credentials too!

Reichstag answered 15/6, 2015 at 1:17 Comment(0)
C
0

Please check that the SonarQube process has the same enviroment variables, as you are using for testing.

Craddock answered 27/2, 2015 at 13:30 Comment(1)
In SonarQube System Info page, under Library Path, I have (among other things) "C:\Program Files\TortoiseSVN\bin" and the svn executable is correctly under that folder.Bruise
L
0

I have just installed SonarQube 5.0.1 on a Redhat Linux machine and I have exactly the same problem.

Instead of disabling the scm stats plugin, I have installed a svn client (svnkit.x86_64) and the build is executed successfully with SCM activated. So I guess on Windows, you should install a svn client and put it on the PATH.

Lumberyard answered 31/3, 2015 at 14:47 Comment(3)
Thanks for your answer but I already have a SVN client installed on the Windows machine (it's TortoiseSVN). With the command prompt, I can successfully execute svn commands.Bruise
Oh I see, have you tried to add the tortoisesvn bin directory directly into the Windows system path? Restart Jenkins after that so the new environment variable is updated.Lexine
Yes, that's actually where I added it. Both SonarQube and Jenkins server were restarted.Bruise

© 2022 - 2024 — McMap. All rights reserved.