Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1791

SonarQube can fail GitLab pipeline based on quality gate results




      Even if we manage to provide a first integration to help teams run SQ analysis as part of their GitLab CI pipelines (MMF-1789), we'd like to go a step further.

      Currently, if the quality gate is failed on SQ side, the SQ step seems successful when looking at the branch inside GitLab. This is because SQ analyses are asynchronous and therefore the scanner always succeeds - whatever the status of the quality gate that will be computed by SQ.

      We'd like to give dev teams to know inside GitLab when the quality gate is red so that they can take appropriate actions.


      Use cases

      As a developer pushing code on a branch or a merge request:

      1. I want my pipeline to fail on the SQ step when the quality gate is red
      2. I want to see that the SQ step is in error
      3. Ideally, I'd like to be able to click somewhere to go and see the details in SQ


      Initial comments:

      • From what we know of GitLab, implementing this feature implies that for GitLab environment, we will need to find a simple way to wait for the report to be processed, get the details and fail the step if the QG is red
        • This might be done inside the scanner engine to make upgrade transparent
        • This might be done with a separate CLI "tool" - but in this case users have to update their CI scripts
      • If it's possible to provide links to SQ, they should point to the branch/merge request overview page

      3 options:

      • Use a 2nd step that waits for the report to be processed and that checks the QG status
      • Uses an API endpoint provided by GitLab to fail/pass the build status
      • Makes the scanner wait and check the QG status

      Because it better fit with GitLab mindset, we've chosen the 3rd option:

      We'll implement a mechanism to make the scanner wait for the Quality Gate status. Users will have to set a new parameter to activate this feature such as sonar.qualitygate.wait=false.

      The logs should clearly show the Quality Status with a link to the branch/merge request overview page to get more details.

      This waiting feature will NOT be activated by default. It will be well explained in the documentation concerning GitLab CI and described within the examples we provide.


      • Add additional options for scanner with defaults to allow waiting for Quality Gate result:
        sonar.qualitygate.wait=false - enable/disable a scanner wait for QG result (value set to `false` if not specified)
        sonar.qualitygate.timeout=300 (s) - set a time in seconds for how long scanner should wait for report to be processed (property is taken into account only if sonar.qualitygate.wait is set to `true`)
      • Add step to scanner engine step just after report is published, so that step can use values from properties to actively poll CE task endpoint (api/ce/task) for status within given time.
        • If task has success status, get Quality Gate status using api/qualitygates/project_status endpoint, otherwise (failed, canceled) stop processing with appropriate reason. In case status pending/ in_progress continue polling until timeout is reached.
        • Failure reason from Quality Gate (or other) should be clearly stated in logs.


          Issue Links



              • Assignee:
                christophe.levis Christophe Levis
                christophe.levis Christophe Levis
              • Votes:
                6 Vote for this issue
                8 Start watching this issue


                • Created: