Project seen as multi-module with jenkins sonarqube scanner

[Tamás Kende]

Hi,

I have the following sonar.properties set in the jenkins sonarqube scanner plugin:

sonar.projectKey=com.bla.bla.bla

sonar.projectName=Bla Bla

sonar.projectVersion=1.0

sonar.language=py

sonar.sources=bla_bla

sonar.tests=tests

sonar.python.xunit.reportPath=junit.xml

sonar.python.coverage.reportPath=coverage.xml

# Encoding of the source files

sonar.sourceEncoding=UTF-8

Sonar scanner version: 2.8

Sonarqube jenkins plugin: 2.5

Sonarqube server: 5.6.3

Jenkins version: 2.32.1

The job keeps failing with:

16:01:13.758 WARN: /!\ A multi-module project can't have source folders, so '/jenkins/workspace/blabla_sonarqube/bla_bla' won't be used for the analysis. If you want to analyse files of this folder, you should create another sub-module and move them inside it.
16:01:13.759 ERROR: Invalid value of sonar.sources for com.bka.bla.bla:bla_bla

...

Caused by: The folder 'bla_bla' does not exist for 'com.bla.bla.bla:bla_bla' (base directory = /jenkins/workspace/blabla_sonarqube/bla_bla)

And yes, the folder exists.
Any idea what goes wrong? I checked the source, and the only way the scanner can think its multi-module is when it has a sonar.modules setting, what I dont have. 

Also I do not have the key set to contain ':bla_bla', I had it before but then removed it can it be stuck somewhere?. In the original setup the source folder name was the same as the last part of the key (bla_bla) but even if I change the key it does not help.

I checked the sonarqube server if it has any ghost projects but I do not see this project there at all.

Thank you for your help

Cheers

Tamas

[janos....@sonarsource.com]

Hi,

I'm not able to reproduce the problem. Here are some observations:

1. It looks as if the working directory of the scanner process is "/jenkins/workspace/blabla_sonarqube". So far that seems normal. Do you agree?

2. "bla_bla" is configured as source directory. The scanner finds a directory with this name inside the working directory, and since somehow it thinks you have modules in this directory, it prints a warning about the presence of sources

3. The scanner thinks "bla_bla" is a module. So it looks for the sources at "/jenkins/workspace/blabla_sonarqube/bla_bla/bla_bla", which doesn't exist, so it fails with an error

Are you absolutely sure that you don't have sonar.modules = bla_bla defined somewhere? For example -Dsonar.modules=bla_bla passed to your build? Because that would produce exactly the behavior you are seeing.

Can you reproduce if you run the scanner on your PC, instead of on Jenkins? If it doesn't happen on the PC then the explanation will be something messed up with the Jenkins job configuration. Cleaning the Jenkins workspace or recreating the job from scratch should help.

Janos

[Tamás Kende]

Hi,

thanks for your response, I am able to reproduce it when I execute it locally:

1. yes, the working dir looks good

2. agree the whole confusion is caused by thinking the current project has modules, so then it makes sense that it ignores the sources of the parent module

3. based on the local reproduction it seems you are right it is looking for the source directory in the source directory

what is confusing to me is the reported key, it is not what is being set by me, but maybe this is some sonar generated key for the source folder? (com.bla.bla.bla:bla_bla -> lets call it com.a.b.c:bla_bla from now on where bla_bla is the source folder)

So I did a test and configured the sonar.sources to contain bla_bla2, and in this case I dont see the multi module error anymore, but the "folder does not exists", which can be because the check is earlier in the code. So I copied the sources to be in bla_bla2 and I got the multi module error again. Same with renaming it to blabla2

Then I thought maybe some sonar python setting is causing troubles so I removed those, but still the same.

At this point I decided to start to debug whats going on, and then I finally found whats causing the problem, it seems the sonarqube server returns with some unexpected properties for the project (maybe a misconfigured attempt to analyse before) my command line argument does not contain sonar.modules but if I set a break point at ProjectReactorBuilder#233 (5.6.3 sonarqube) I see its being set (or some other mechanism sets it not the server). Any idea what is going on? How can I fix it without deleting my other project from sonarqube server.

Thanks for your help

Cheers

Tamas

[Janos Gyerik]

Hi,

If I understand correctly, you've verified in the debugger that sonar.modules is set when you run the scanner, and you don't know where that comes from. 

The setting cannot come from the server. It can come from multiple places in your environment, in this order:

- Global properties: the conf/sonar-scanner.properties in the installation directory of the scanner CLI

- Project properties: the sonar-project.properties of your project

- System properties: Java's System.getProperties()

- Environment properties: the environment variable SONARQUBE_SCANNER_PARAMS

- CLI properties: the -D properties passed on the command line

Verify all these locations. As a last resort, you could put a breakpoint in the Conf class (as you seem comfortable with the debugger), and observe the content of properties as you step through each action.

Let me know how it goes.

Cheers,

Janos

--

Janos GYERIK | SonarSource

http://sonarsource.com

[Tamás Kende]

Hi,

thank you! that solved the mystery, indeed there was a sonar-runner.properties what I was not aware of at all. I feel a bit stupid now, but at least its solved

Thank you for your help,

Cheers

Tamas