Erreur dans SonarQube lors du lancement de svn blame
J'ai récemment mis à jour ma SonarQube serveur à partir 4.5.2 pour 5.0.1, puis à 5.1 (voir modifier ci-dessous).
Soudain, l'analyse d'un multi-module Maven projet 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 moreEn quelque sorte, la commande svn ne trouve pas le fichier src/main/java/MyClass.java dans le répertoire C:\somedirectory\module1bien que ce fichier est bien là. Si je copie-coller la commande SonarQube est d'essayer de l'exécuter dans une invite de commande svn blame --xml --non-interactive -x -w src/main/java/MyClass.java à l'intérieur de répertoire C:\somedirectory\module1 alors la commande fonctionne bien.
svn de commande est correctement sur le CHEMIN, comme on peut le voir dans le "Chemin de la Bibliothèque" champ "Info Système" à la page dans SonarQube serveur. SonarQube serveur est hébergé sur le même serveur où mvn sonar:sonar a été exécuté (Windows Server 2008 R2).
svn lancé par SonarQube pour récupérer le blâme l'histoire. Ce que je comprends, il y avait quelques changements faits dans SonarQube 5.0 concernant SCM soutien (modification intégrée). Ma solution pour l'instant est de désactiver le SCM capteur de SonarQube (à l'aide de -Dsonar.scm.disabled=true ou directement dans le SonarQube serveur, sous "Paramètres > Paramètres > SCM").
Ce n'est pas lié à cette question depuis je n'ai rencontré que le comportement lorsque j'ai mis à SonarQube 5.0.1.
JRE utilisé : 1.7.0_51 (64 bits)
EDIT :
Après une mise à niveau de SonarQube 5.1, l'erreur est toujours là, mais le message est différent et plus claire. J'ai réinstallé un client SVN (TortoiseSVN) et redémarré à la fois Jenkins et SonarQube, mais l'erreur reste:
SCM fournisseur a été fixé à "svn", mais pas de SCM fournisseur trouvé pour cette clé. Pas de SCM fournisseur 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 moresource d'informationauteur Tunaki
Vous devez vous connecter pour publier un commentaire.
J'ai connu le même problème après l'installation de SonarQube 5.1, allez à la Centre de mise à Jour:
de recherche pour le "SVN"cliquez sur "Installer"
Quelque chose comme cela apparaîtra:
Redémarrez votre SonarQube.
utiliser la commande ci-dessous qui va désactiver le svn questions liées à la
cela va désactiver le svn
Ce problème peut se résoudre de deux façon,
1. en définissant le sonar.propriétés -Dsonar.scm.disabled=True, ceci est valable uniquement pour les sonarrunner.chauve-souris sonar analyse,
2. Si vous faites l'utilisation de tout autre type d'analyse puis connectez-vous avec l'admin admin par défaut est admin/admin(nom d'utilisateur/mot de passe).http://yourDomin:port/settings/index(e.g http://localhost:9000/settings/index) puis dans la catégorie sélectionnez la scm et de désactiver le scm du capteur comme vrai.
3.ou alors u peut ajouter le svn du plugin pour le sonar http://your_domain:port/updatecenter/available après la connexion en tant qu'administrateur(admin/admin), recherche pour le plugin et sélectionnez le svn et l'installer..
J'ai eu ce problème et il a été causé en n'ayant pas un actif d'installation de SVN sur la machine de compilation qui a été exécuté le sonar de l'analyse. Il n'a pas d'importance ce que le sonar zone de a installé. C'est l'accumulation de l'agent qui doit faire le SVN blâmer.
J'ai été en utilisant CentOS. La magie était
La dernière astuce est de faire en sorte que la machine de compilation a été en utilisant la même version de SVN pour la caisse que la version que j'ai installé. Si la construction de la machine est en mode natif à l'aide d'une version différente, vous pourriez avoir à assurez-vous qu'il nettoie l'ensemble de l'espace de travail avant sa prochaine découvrez aussi.
Enfin, n'oubliez pas que le Sonar a besoin de votre SVN informations d'identification de trop!
Veuillez vérifier que le processus de SonarQube a le même environnement de variables, que vous utilisez pour effectuer des tests.
Je viens d'installer SonarQube 5.0.1 sur une Redhat Linux machine, et j'ai exactement le même problème.
Au lieu de désactiver la scm stats plugin, j'ai installé un client svn (svnkit.x86_64) et la construction est exécutée avec succès avec SCM activé.
Donc je suppose que sur Windows, vous devez installer un client svn et la mettre sur le CHEMIN.