J'ai récemment mis à niveau mon serveur SonarQube de 4.5.2 à 5.0.1, puis à 5.1 (voir modification ci-dessous).
Soudain, l'analyse d'un projet Maven multi-module a échoué avec l'erreur suivante:
[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
D'une manière ou d'une autre, la commande svn
n'a pas trouvé le fichier src/main/Java/MyClass.Java
dans le répertoire C:\somedirectory\module1
, bien que ce fichier y soit vraiment. Si je copie-colle la commande que SonarQube tente d'exécuter dans une commande Invite svn blame --xml --non-interactive -x -w src/main/Java/MyClass.Java
du répertoire C:\somedirectory\module1
, la commande fonctionne correctement.
La commande svn
est correctement sur le chemin PATH, comme le montre le champ "Chemin de la bibliothèque" de la page "Informations système" du serveur SonarQube. Le serveur SonarQube est hébergé sur le même serveur où mvn sonar:sonar
a été exécuté (Windows Server 2008 R2).
svn
est lancé par SonarQube pour récupérer l'historique des fautes. Si j'ai bien compris, certaines modifications ont été apportées à SonarQube 5.0 en ce qui concerne la prise en charge de SCM (modification intégrée). Ma solution consiste à désactiver le capteur SCM dans SonarQube (avec -Dsonar.scm.disabled=true
ou directement sur le serveur SonarQube, sous "Paramètres> Paramètres généraux> SCM").
Ce n'est pas lié à cette question } _ car je n'ai rencontré ce problème que lorsque j'ai effectué la mise à niveau vers SonarQube 5.0.1.
JRE utilisé: 1.7.0_51 (64 bits)
MODIFIER :
Après une mise à niveau vers SonarQube 5.1, l'erreur est toujours là mais le message est différent et plus clair. J'ai réinstallé un client SVN (TortoiseSVN) et redémarré Jenkins et SonarQube, mais l'erreur persiste:
Le fournisseur SCM a été défini sur "svn" mais aucun fournisseur SCM n'a été trouvé pour cette clé. Aucun fournisseur SCM installé
[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
J'ai rencontré le même problème après l'installation de SonarQube 5.1. Allez à Centre de mise à jour:
rechercher le "SVN"}, cliquez "Installer"
Quelque chose comme ça va apparaître:
SonarQube doit être redémarré pour pouvoir installer le fichier .__ suivant. plugins: sonar-scm-svn-plugin-1.0.jar
Redémarrez votre SonarQube.
utilisez la commande ci-dessous qui désactivera les problèmes liés à svn
-Dsonar.scm.disabled=True
cela va désactiver le svn
Ce problème peut être résolu de deux manières,
1. en définissant le sonar.properties -Dsonar.scm.disabled = True, ceci n’est valable que pour l’analyse du sonar sonarrunner.bat,
2. Si vous utilisez une autre analyse de type, connectez-vous avec admin par défaut admin est admin/admin (nom d'utilisateur/mot de passe) . http: // yourDomin: port/settings/index (par exemplehttp: // localhost: 9000/settings/index ) puis dans la catégorie, sélectionnez la scm et désactivez le capteur scm défini sur true.
3.ou sinon, vous pouvez ajouter le plug-in svn au sonar http: // votre_domaine: port/updatecenter/available après vous être connecté en tant qu'administrateur (admin/admin), recherchez le plug-in disponible et sélectionnez le svn et l'installer ..
J'ai eu ce problème et cela était dû à l'absence d'installation active de SVN sur la machine de construction qui exécutait l'analyse sonar. Peu importe ce que le boîtier sonar a installé. C'est l'agent de construction qui doit blâmer le SVN.
J'utilisais CentOS. La magie était
Sudo yum install svn
L'astuce finale consistait à vérifier que la machine de compilation utilisait la même version de SVN pour le paiement que la version que j'ai installée. Si la machine de compilation utilisait de manière native une version différente, vous devrez peut-être vous assurer qu'elle nettoie tout l'espace de travail avant sa prochaine extraction.
Enfin, n'oubliez pas que Sonar a également besoin de vos informations d'identification SVN!
Vérifiez que le processus SonarQube a les mêmes variables d’environnement que celles que vous utilisez pour les tests.
Je viens d'installer SonarQube 5.0.1 sur une machine Linux Redhat et j'ai exactement le même problème.
Au lieu de désactiver le plug-in scm stats, j'ai installé un client svn (svnkit.x86_64) et la construction est exécutée avec succès. SCM est activé . Je suppose donc que sous Windows, vous devez installer un client svn et le placer sur le chemin PATH. .