Running in Jenkins version 2.150.2
SonarQube version 6.7 (upgrade to latest LTS is planned for later this year).
Sonar Scanner 3.3
Jenkins SonarQube plugin version 2.9
Jenkins Quality Gates plugin version 2.5
Jobs are no longer failing using the following quality gate definition. We even introduced bad, new code to force it to fail but it did not.
Yes. The concept got renamed. Sorry for the confusion.
Thanks for the screenshot and the web service response. I see 2 things here:
Your New Code/Leak Period is set to previous_analysis. That means that if I do introduce a Quality Gate-breaking change, I only have to run another new analysis for it to go away. Probably what you wanted here is previous_version, which ought to be a longer period - assuming you don’t feed your build number into the sonar.projectVersion analysis parameter.
The result of your web api call doesn’t match the Quality Gate Screenshot you sent. It reflects a Quality Gate that tests these conditions:
minor new issues
It looks like maybe you have multiple Quality Gates in play and something other than what you expect is being applied.
What does the web service say? Unless you’ve changed which Quality Gate is applied to your project then it’s perfectly predictable that the project didn’t fail the QG. As a reminder, your previous web service call indicated that only the following criteria are applied:
minor new issues
So you need to double-check (in the right rail of the project hompage) which Quality Gate is being applied.
Hi Ann. I did check and it is ILI_Gate, the one I pasted. I just noticed this message: It didn’t include that in the log sent back to Jenkins.
In the Jenkins log the Sonar step ends with “Execution Successful”, which simply means the scan succeeded, but not reporting the result of the scan.
Our Jenkins job is set up to fail if the Sonar scan files but it doesn’t seem like Sonar is sending a failed scan message anywhere.
I’ve attached the Sonar output that shows up in Jenkins.Sonar Output.txt (8.6 KB)
It looks like this is a question of your Jenkins job configuration. I don’t see any indication in your Jenkins log that it’s waiting for the QG status to be calculated. Can you share your job/pipeline configuration? Note that it should look something like this.
And with webhook delivery, introduced in Sonarqube 6.2 it’s not needed anymore.
After background task has finished, Sonarqube server sends JSON to Sonarqube Jenkins plugin, which consumes the payload and breaks the build if quality gate is violated.
This works only with Jenkins pipelines, not with classis jobs.
i would go
use only Jenkins pipelines, no classic jobs
deinstall Jenkins quality gate plugin
configure Sonarqube webhooks
make sure the communication Jenkins <-> Sonarqube server works both ways
then your pipeline will fail if quality gate violations
Thank you Gilbert. I’ve been reading up on the webhooks and am not sure how it would send the response back to each individual job because it’s URL based. A maximum of 20 webhooks can be created. Each job execution has it’s own URL so obviously we can’t create a webhook for each one. Is there a way to configure the webhooks so the response from Sonar can be read by the pipeline that triggered the scan?
no, it’s not that every job execution has its own url, but his own unique analysisid.
e.g. in Sonarqube web ui see /admin/background_tasks , the ID column has the analysisid.
Our Sonarqube Enterprise instance uses only 1 global webhook for Jenkins, configured
like https://somejenkinshost/sonarqube-webhook/, it’s one static url for all jobs.
Everytime when CE on Sonarqube server has completed a background task of an analysis
(= computing the report archive uploaded by the Sonar Scanner on Jenkins) it triggers a webhook,
sending a JSON playload that contains the analysisid beside branch name, quality gate result …
You will notice two different scenarios in Jenkins pipelines. If the background task has finished
in no time, the quality gate result is available immediately (Sonar Scanner does an initial call for quality gate result after upload) - no need to wait for webhook.
Otherwise the waitForQualityGate() method of Sonarqube Jenkins plugin creates a listener for
this specific analysisid waiting for / consuming the payload with the matching analysisid.
The Jenkins log shows status PENDING in that case.
A timeout of 10mins is sufficient for all our jobs.