2015-02-26 8 views
14

Ich habe kürzlich meinen SonarQube-Server von 4.5.2 auf 5.0.1 und dann auf 5.1 aktualisiert (siehe unten).Fehler in SonarQube beim Starten von SVN-Schuld

Plötzlich die Analyse eines Multi-Modul Maven Projekt scheiterte mit dem folgenden Fehler:

[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 

Irgendwie der Befehl svn die Datei nicht src/main/java/MyClass.java im Verzeichnis C:\somedirectory\module1 gefunden hat, obwohl die Datei auf jeden Fall da. Wenn ich den Befehl, den SonarQube versucht, in einer Eingabeaufforderung svn blame --xml --non-interactive -x -w src/main/java/MyClass.java innerhalb Verzeichnis C:\somedirectory\module1 auszuführen, kopieren, fügen Sie den Befehl ein, dann funktioniert der Befehl einwandfrei.

svn Der Befehl ist korrekt im Pfad, wie im Feld "Bibliothekspfad" auf der Seite "System Info" im SonarQube-Server zu sehen ist. Der SonarQube-Server wird auf demselben Server gehostet, auf dem mvn sonar:sonar ausgeführt wurde (Windows Server 2008 R2).

svn wird von SonarQube gestartet, um Schuldzuweisungen zu erhalten. Wie ich es verstehe, there were some changes made in SonarQube 5.0 concerning SCM support (Wechsel zu Built-in). Meine Abhilfe besteht derzeit darin, den SCM-Sensor in SonarQube zu deaktivieren (über -Dsonar.scm.disabled=true oder direkt auf dem SonarQube-Server unter "Einstellungen> Allgemeine Einstellungen> SCM").

Dies steht nicht mit this question in Verbindung, da ich dieses Verhalten nur beim Upgrade auf SonarQube 5.0.1 festgestellt habe.

JRE verwendet: 1.7.0_51 (64 Bit)

EDIT:

Nach einem Upgrade auf Sonarqube 5.1 ist der Fehler immer noch hier, aber die Botschaft ist anders und klarer. Ich habe einen SVN-Client (TortoiseSVN) neu installiert und neu gestartet beide Jenkins und Sonarqube aber der Fehler bleibt:

SCM-Anbieter wurde auf „svn“ gesetzt, aber kein SCM-Anbieter für diesen Schlüssel gefunden. Keine SCM-Provider installiert

[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 
+0

Fehler ist sehr komplex, sollten Sie wählen ein Stück von ihnen – dewelloper

+3

@ HamitYıldırım Ich stimme nicht zu, alle StackTrace könnte für jemanden relevant sein, um das Problem zu debuggen. Und es ist nicht so lang. – Tunaki

Antwort

8

Ich habe das gleiche Problem nach der Installation von SonarQube 5 erfahren.1, gehen Sie zu Update Center:

http://your_domain:port/updatecenter/available

Suche nach dem "SVN", klicken Sie auf "Install"

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

Etwas wie folgt angezeigt:

Sonarqube benötigt, um neu gestartet wird folgende Plugins zu installieren: Sonar-scm-svn-plugin-1.0.jar

Starten Sie Ihre Sonarqube.

+0

Ja, das hat es genagelt! Ich habe nicht bemerkt, dass es ein neues SVN-Plugin gab. Dies sollte unbedingt in den Upgrade-Hinweisen erwähnt werden. – Tunaki

+0

Ich kann das gleiche für Git bestätigen. Wir haben unseren Sonarqube von 4.5 auf 6.4 auf einem neuen Server verschoben. Der alte Server hatte eine Git-Installation. Mit dem git-plugin [link] (https://docs.sonarqube.org/display/PLUG/Git+Plugin) habe ich das Problem gelöst. – Markus

0

Bitte überprüfen Sie, dass der Sonarqube Prozess die gleichen Umgebungsvariablen hat, wie Sie zum Testen verwenden.

+0

Auf SonarQube 'System Info' Seite, unter' Bibliothekspfad ', habe ich (unter anderem) '" C: \ Programme \ TortoiseSVN \ bin "' und die 'svn' Executable ist korrekt unter diesem Ordner. – Tunaki

34

benutzen Sie das folgende Kommando, das wird die SVN Fragen

-Dsonar.scm.disabled=True 

dies die SVN

+0

Das habe ich schon gemacht. Ich habe den SCM-Sensor auf dem SonarQube-Server deaktiviert und er funktioniert ohne ihn. Aber ich möchte, dass es mit dem SCM-Sensor funktioniert. – Tunaki

+3

"mvn sonar: sonar -Dsonar.scm.disabled = Wahr". Arbeitete für mich. Danke – Morvader

0

ich installiert habe nur Sonarqube wird deaktivieren deaktivieren 5.0.1 auf einem Redhat Linux-Maschine und ich habe genau das gleiche Problem.

Anstatt das scm stats Plugin zu deaktivieren, habe ich einen Svn Client (svnkit.x86_64) installiert und der Build wurde erfolgreich mit SCM aktiviert. Also ich denke, unter Windows sollten Sie einen Svn-Client installieren und auf den Pfad setzen.

+0

Danke für deine Antwort, aber ich habe bereits einen SVN-Client auf dem Windows-Rechner installiert (es ist TortoiseSVN). Mit der Eingabeaufforderung kann ich Svn-Befehle erfolgreich ausführen. – Tunaki

+0

Oh ich sehe, haben Sie versucht, das Verzeichnis tortoisesvn bin direkt in den Windows-Systempfad hinzuzufügen? Starten Sie Jenkins danach neu, damit die neue Umgebungsvariable aktualisiert wird. –

+0

Ja, das ist tatsächlich, wo ich es hinzugefügt habe. Sowohl SonarQube als auch Jenkins Server wurden neu gestartet. – Tunaki

1

Ich hatte dieses Problem und es wurde verursacht, indem ich keine aktive Installation von SVN auf der Erstellungsmaschine hatte, die die Sonaranalyse ausführte. Es spielt keine Rolle, was die Sonar Box installiert hat. Es ist der Build-Agent, der die SVN-Schuld zu tun hat.

Ich habe CentOS verwendet. Die Magie war

sudo yum install svn 

Der letzte Trick, um sicherzustellen, war, dass die Build-Maschine zur Kasse als die Version der gleiche Version von SVN war ich mit installiert. Wenn der Build-Computer nativ eine andere Version verwendet, müssen Sie möglicherweise sicherstellen, dass er den gesamten Arbeitsbereich vor dem nächsten Auschecken bereinigt.

Schließlich vergessen Sie nicht, dass Sonar auch Ihre SVN-Anmeldeinformationen benötigt!

+0

Und wie SVN-Anmeldeinformationen für Sonar angeben? Das kann ich nicht finden ... – Betlista

7

Dieses Problem kann durch zwei Art und Weise lösen werden,
1. durch die sonar.properties Einstellung -Dsonar.scm.disabled = True, dies nur für sonarrunner.bat Sonar Analyse gültig ist,
2. Wenn Ihr tun Wenn Sie eine andere Typanalyse verwenden, melden Sie sich mit admin default admin an admin/admin (Benutzername/Passwort). http://yourDomin:port/settings/index(e.ghttp://localhost:9000/settings/index) dann in der Kategorie wählen Sie die scm und deaktivieren Sie den SCM-Sensor als wahr eingestellt.
3.oder sonst können Sie das SVN-Plugin zum Sonar hinzufügen http://your_domain:port/updatecenter/available nach dem Login als admin (admin/admin), suchen Sie nach dem verfügbaren Plugin und wählen Sie die Svn und installieren Sie es ..