0

I have a Pipeline script with two steps.

  • SonarQube analysis
  • UnitTests

If the SonarQube finds warnings, it reports them back to Gerrit as comments and set the Code-review-1. The next stage is the UnitTest and if it is OK the Pipeline will be successful and the Jenkins should report back to Gerrit Verified+1. BUT, when Jenkins reports the Verified+1 then it removes the Code-review-1.

Related part of my Pipeline script:

....
    steps {
        withSonarQubeEnv('Managed SonarQube') {
            sh '''./sonar_runner.sh preview'''
            sonarToGerrit(
                inspectionConfig: [
                    serverURL: env.'SONAR_HOST_URL',
                    baseConfig: [
                        sonarReportPath: '.scannerwork/sonar-report.json',
                        autoMatch: true
                    ]
                ],
                scoreConfig: [
                    issueFilterConfig: [
                        severity: 'MINOR',
                        newIssuesOnly: false,
                        changedLinesOnly: false
                    ],
                    category: 'Code-Review',
                    noIssuesScore: 0,
                    issuesScore: -1
                ]
            )
        }
        stage('UnitTest') {
            steps {
                ansiColor('xterm') {
                    sh '''./unittest.sh'''
                }
      ....

My "Gerrit Reporting Values" section:

Gerrit Reporting Values section

My Gerrit history:

Gerrit history

My final result:

Final result

My question:

How can I set the the Code-review-1 and Verified+1 in one running? How can I avoid that Gerrit removes the Code-review-1 when reports Verified+1? I am open to GUI solution as well as Pipeline.

EDIT:

It is not option to change the global config of Gerrit plugin. I have to solve it on Jenkins job level. Is it possible?

milanbalazs
  • 4,811
  • 4
  • 23
  • 45
  • Hi @milanbalazs, do you mind sharing your Jenkinsfile on how to report sonarqube findings as comments back to gerrit? Thank you . – Frank Liu Jul 28 '21 at 02:05
  • Hi @FrankLiu, No Problem, I have extended my question with the complete Sonar block. If you have more questions, just feel free to ask. :) – milanbalazs Jul 28 '21 at 03:49
  • Thank you so much for a prompt reply. I do have a follow up. Are u using the [sonar-gerrit](https://plugins.jenkins.io/sonar-gerrit/) plug to achieve this feature? From the plugin's website, it seems that it is no longer compatible with SonarQube 7.7 or later. We are planning to use SonarQube 8.9 LTS and gerrit 3.3.1. Are you aware any tools that can help us achieve the same results with slightly newer SonarQube and Gerrit? Cheers. – Frank Liu Jul 28 '21 at 04:00
  • Yeah, I am using the `sonar-gerrit` Plug-In to report back the defects to Gerrit. My Gerrit version is 2.14.22 and the SonarQube version is 7.9.4 and it works with Gerrit. Only the `preview` feature is not available anymore. I have implemented that feature in the `sonar_runner.sh` script. If you are interested this implementation, let me know. – milanbalazs Jul 28 '21 at 04:07
  • I see. Only the `preview` feature. I not even sure what the `preview` feature of SonarQube is. Let me do some research. I will try to integrate sonarqube 8.9 with gerrit 3.3.1 using `sonar-gerrit plugin version 2.4.3` Thanks again for your input. – Frank Liu Jul 28 '21 at 04:15
  • The `preview` mode when you don't store your report to Sonar server only compare the local report with the server report to get the new defects in your local report (Based on this, you can report back the new defect to Gerrit). Since this feature is not available longer you have to implement this feature in `sonar_runner.sh` script that you have to create a temporary branch for your local report and you have to compare the temp. branch with your "master" branch and with this solution you can get the new Sonar defects to report back to Gerrit them. – milanbalazs Jul 28 '21 at 04:21
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/235366/discussion-between-frank-liu-and-milanbalazs). – Frank Liu Jul 28 '21 at 04:24

2 Answers2

2

I think you must leave an empty string in the "Code Review" fields. The "0" value means you want to remove the previous vote. But you need also to check the global gerrit-trigger configuration at

Jenkins > Manage Jenkins > Gerrit Trigger > Edit > Gerrit Reporting Values.
  • Thanks for your answer. You are totally right, I am up-voting you answer! However, It's my fault, I didn't mentioned in my question that I have to solve the issue in Jenkins job level, so I am not able to change the Gerrit global config (We can say I have permissions only for the job, not for global configs). It means, unfortunately, your solution is not possible in my case. I have updated my question with this (quite important) detail. – milanbalazs Oct 22 '19 at 21:27
  • I understand. What if you ask the Jenkins administrators to create another "Gerrit Server" in the gerrit-trigger configuration? This server could be named "Gerrit-No-Votes" and have empty string in all "Verify" and "Code Review" fields. People can choose which server will be used in the job configuration. – Marcelo Ávila de Oliveira Oct 23 '19 at 11:51
0

First of all, as I mentioned in my question the global Gerrit config change and new Gerrit server were not option for me. I needed to solve this problem on Jenkins job level.

I have found a "solution" which is rather a work-around, but it works.

Step 0:

If you check the STDOUT of SonarQube in the Jenkins console log, you can see a specific line which indicates the number of issues which are effected of score calculation. This line is: Issues to be involved in score calculation: X. It means you can know if there is effected issues or not based on this line.

Jenkins console log

Step 1:

You should check the Jenkins console log and find the number of issues which are involved in score calculation. You can see below my implementation for it. If there is issue (The RegEx value is not zero) then this stage should set the build result to UNSTABLE.

stage('Results') {
            steps {
                script{
                        for(String line : currentBuild.getRawBuild().getLog(30)){
                            def find_pattern = (line =~ /^Issues to be involved in score calculation: [1-9]/)
                            if(find_pattern){
                                echo line
                                echo "Sonar has found warnings in changed lines. Build goes to UNSTABLE."
                                currentBuild.result = "UNSTABLE"
                            }
                        }
                    }

Example output of how it works:

Report has loaded and contains 1021 issues
Issues to be commented: 1
Issues to be involved in score calculation: 1
Review has been sent
[Pipeline] }
[Pipeline] // withSonarQubeEnv
[Pipeline] }
[Pipeline] // ansiColor
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Results)
[Pipeline] script
[Pipeline] {
[Pipeline] echo
Issues to be involved in score calculation: 1
[Pipeline] echo
Sonar has found warnings in changed lines. Build goes to UNSTABLE.

Step 2:

Configure the Gerrit Reporting Values block to report back the both values (CR and Verified labels) back to Gerrit in case of UNSTABLE Build result.

enter image description here

milanbalazs
  • 4,811
  • 4
  • 23
  • 45