Недавно я обновил свой сервер SonarQube с 4.5.2 до 5.0.1, затем до 5.1 (см. ниже).
Неожиданно анализ мультимодульного проекта Maven завершился с ошибкой:
[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
Как-то команда svn не нашла файл src/main/java/MyClass.java в каталоге C:\somedirectory\module1, хотя этот файл определенно существует. Если я скопирую-вставку команды SonarQube пытается выполнить в командной строке svn blame --xml --non-interactive -x -w src/main/java/MyClass.java внутри каталога C:\somedirectory\module1, тогда команда работает нормально.
svn команда корректна в PATH, как это видно в поле "Путь к библиотеке" на странице "Информация о системе" на сервере SonarQube. Сервер SonarQube размещен на том же сервере, на котором был выполнен mvn sonar:sonar (Windows Server 2008 R2).
svn запускается SonarQube для извлечения истории вины. Насколько я понимаю, произошли некоторые изменения, внесенные в SonarQube 5.0 относительно поддержки SCM (переход на встроенный). Моим обходным решением сейчас является отключить датчик SCM в SonarQube (используя -Dsonar.scm.disabled=true или непосредственно на сервере SonarQube в разделе "Настройки > Общие настройки > SCM" ).
Это не связано с этим вопросом, так как я только столкнулся с этим поведением при обновлении до SonarQube 5.0.1.
Используется JRE: 1.7.0_51 (64 бит)
EDIT:
После обновления до SonarQube 5.1 ошибка все еще здесь, но сообщение отличается и более понятным. Я переустановил SVN-клиент (TortoiseSVN) и перезапустил Jenkins и SonarQube, но ошибка остается:
Поставщик SCM был настроен на "svn", но для этого ключа SCM-провайдер не найден. Поставщик SCM не установлен
[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
У меня возникла такая же проблема после установки SonarQube 5.1, перейдите в Центр обновлений:
найдите "SVN" , нажмите "Установить"
Появится следующее:
Снова необходимо перезапустить SonarQube, чтобы установить следующие плагины: sonar-scm-svn-plugin-1.0.jar
Перезагрузите свой SonarQube.
используйте следующую команду, которая отключит связанные с svn проблемы
-Dsonar.scm.disabled=True
это отключит svn
Эта проблема может быть решена двумя способами:
1. установив sonar.properties -Dsonar.scm.disabled = True, это справедливо только для анализа sonarunner.bat сонара,
2. Если вы используете какой-либо другой анализ типов, то войдите в систему с admin admin admin admin/admin (имя пользователя/пароль). http://yourDomin:port/settings/index(e.g http://localhost:9000/settings/index), тогда в категории выберите scm и отключите датчик scm как истинный.
3. или еще вы можете добавить плагин svn к сонару http://your_domain:port/updatecenter/available после входа в систему как admin (admin/admin), найти доступный плагин и выберите svn и установите его.
У меня была эта проблема, и это было вызвано отсутствием активной установки SVN на машине сборки, которая выполняла анализ сонара. Неважно, что установил ящик сонара. Это агент сборки, который должен выполнить вину SVN.
Я использовал CentOS. Магия была
sudo yum install svn
Последний трюк состоял в том, чтобы убедиться, что машина сборки использовала ту же версию SVN для проверки, что и версия, которую я установил. Если сборка была изначально использована в другой версии, вам, возможно, придется убедиться, что она очищает всю рабочую область до ее следующей проверки.
Наконец, не забывайте, что Sonar также нуждается в ваших учетных данных SVN!
Пожалуйста, проверьте, что процесс SonarQube имеет те же переменные среды, что и для тестирования.
Я только что установил SonarQube 5.0.1 на машине Redhat Linux, и у меня точно такая же проблема.
Вместо отключения плагина scm stats я установил svn-клиент (svnkit.x86_64), и сборка успешно выполнена с включенным SCM. Поэтому я полагаю, что в Windows вы должны установить клиент svn и поместить его в PATH.