Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
Windows Server 2008
Description
VERSION:
Jenkins 1.573
Subversion Plugin 2.4.1
Sonar Plugin 2.1
When using multiple SVN Url's in one project, with each set to the following:
Repository URL: http://svnserver/repo/Project/module1/trunk/src
Local Module Directory: module1
Repository URL: http://svnserver/repo/Project/module2/trunk/src
Local Module Directory: module2
...
My sonar.ProjectBaseDir is being set improperly, causing builds to fail. Where the property in this case should be set to C:\Jenkins\Jobs\Project\Workspace , it is instead being set to C:\Jenkins\Jobs\Project\Workspace\module1
When trying to set the property manually with
sonar.ProjectBaseDir=$WORKSPACE
it comes out as -Dsonar.projectBaseDir=D:JenkinsjobsProjectNameworkspace (No slashes)
Any attempts to backreference sonar properties to the workspace parent folder have proven unsuccessful
Attachments
Activity
Cannot reproduce the issue (haven't used your config exactly of course, but still, two locations checked out, both in subdirs, 'echo $WORKSPACE' in the shell...
Do you have env-inject installed? If so, what version? What happens when you disable it, or could you set up a pristine Jenkins instance and try to reproduce the issue there?
Shawn Cole
added a comment - Sorry Daniel, thanks for your troubleshooting, it seems the problem isn't related the to Workspace Environment Variable, but rather the sonar plugin. The Env-Inject Plugin is not installed on this instance.
Shawn Cole
added a comment - Sorry Daniel, thanks for your troubleshooting, it seems the problem isn't related the to Workspace Environment Variable, but rather the sonar plugin. The Env-Inject Plugin is not installed on this instance. And you even had echo %WORKSPACE% in there...
FWIW it's almost sure SCM.getModuleRoot returning the first checked out module directory being used to set Sonar base directory. I observed the same braindead behavior with the Gradle plugin.
Johannes Gmeiner
added a comment - Is there any solution or workaround for this issue? I have the same problem with Jenkins 1.634 and SonarQube plugin 2.3... The SonarQube plugin always takes the first of many modules (checked out from subversion) as sonar.projectBaseDir...
Johannes Gmeiner
added a comment - Is there any solution or workaround for this issue? I have the same problem with Jenkins 1.634 and SonarQube plugin 2.3... The SonarQube plugin always takes the first of many modules (checked out from subversion) as sonar.projectBaseDir... We have the same problem with Jenkins 1.651 and SonarQube plugin 2.4.4
Reducing priority as this does not result in crash or data loss, and seems to have an easy workaround in using the parent directory of the provided WORKSPACE.
Please provide a sample job config.xml file.
Please specify the version of Jenkins and Subversion plugin (we're not using the Jira version fields).