-
versions used (SonarQube Scanner 2.8.1, Jenkins 2.138.1)
-
error observed
The Quality-Gate-Check is called with the wrong taskID because the ID comes from
the wrong report-task.txt. -
steps to reproduce
We have some modules defined in a pom.
For each module sonar is called.Each sonar-call ends up in checking the Quality-Gate with an ID.
But the second id is the same as the first one, because of the
alphabetical order of the report-tast.txt’s.For example:
We have 2 Modules called NameA and NameB
You will find in the logs:
(…)
[SONAR: NameA] [INFO] More about the report processing at https://…/sonar/api/ce/task?id=NameA
(…)
[Pipeline] [SONAR NameA] waitForQualityGate
[SONAR: NameA] Checking status of SonarQube task ‘NameA’ on server ‘sonar’
(…)
[SONAR: NameB] [INFO] More about the report processing at https://…/sonar/api/ce/task?id=NameB
(…)
[SONAR: NameB] WARN: Found multiple ‘report-task.txt’ in the workspace. Taking the first one.
[SONAR: NameB] /NameA/report-task.txt
[SONAR: NameB] /NameB/report-task.txt
(…)
[Pipeline] [SONAR NameB] waitForQualityGate
[SONAR: NameB] Checking status of SonarQube task ‘NameA’ on server ‘sonar’-> So the check for module NameB ist called with taskId NameA
-
potential workaround
Sort the modules in reverse alphabetical order.
-
possible related links:
https://groups.google.com/forum/#!topic/sonarqube/2q5lU5vWTxs
https://jira.sonarsource.com/browse/SONARJNKNS-281
Hi,
I’ll be honest and say this is not a scenario we anticipated: multiple analyses and QG checks in a single job/workspace. What’s supposed to happen if the QG of Module A fails? Module B isn’t analyzed? While it doesn’t seem unreasonable to me that you want to analyze your modules separately, now that we’re treating them as separate projects it does seem unreasonable that you wouldn’t analyze one project because another wasn’t up to snuff.
You should probably do this in separate Jenkins jobs.
Ann
Hello Ann,
thank you for the quick answer.
Let me explain what and why we are doing this.
We analyse all single modules in a loop.
So every module will be analysed and get an own quality gate status.
Each quality status will be available in the build overview of jenkins.
If any of it fails, the jenkinsjob will fail.
We do not analyse the whole multimodule because we need to define different
quality-gates for the submodules. As far as i know this is not possible
in a sonar multimodule.
Also we can not do this in separate jenkins job, because this is a
pipeline that is responsible for building, testing, deploying and
at least analysing the whole project.
I think the scanner in version 2.6.1 was able to handle this scenario
and i experienced that this is a very common one.
It would be nice, if this feature will be available again.
Thank you,
Andreas.
Hi,
Out of curiosity, why do you need a different quality gate on each module of the same project?
BTW, I’m guessing that your use case would be nicely handled by an Application, altho that functionality is only available starting with Enterprise Edition($).
Ann
Hi @Andreas,
AFAIK the only way to support that is to clean the report-task.txt of the previous analysis, to ensure that the correct one will be used. So edit your pipeline to clean after each module analysis (running mvn clean on the module should do the trick, assuming you run the analysis with the scanner for Maven).
++
Hi Julien,
you are right, this workaround works as well as calling the modules in reverse alphabetical order.
But in both cases a parallel processing of the different sonar tasks will not work correctly.
Andreas
Hi Ann,
to satisfy your curiosity:
In our multimodule we have submodules of different concerns.
Some submodules will run in production environment while others
just in development environments or e.g. provide testing functionalities.
The more important the submodules are, the more restrictive
are the quality-gates.
Andreas.