SonarQube - Mandatory and Optional Quality Gate on same code without running scanner twice

SonarQube
, , , ,
1

Hi all,

Version: SonarQube 9.2.2 enterprise edition with Azure Pipelines.

We are trying to mature our code base and want to nudge developers to do even better. Therefore, we want to introduce an optional/target quality gate that we can show but not enforce (yet).

As an example lets say we follow the sonar way with a code coverage of 80 %, but we want to work towards 85%.
Here we want to block the build if the 80% is or is not reached, but also want to show if the 85% is reached or not.
We could like to have a CI/CD pipeline that is a fast as possible and avoid running a scan twice.

We need some advise in if and how we can reach this desired functionality?

An example of our Azure Pipeline for .net with a single quality check:

- task: SonarQubePrepare@4
  inputs:
    SonarQube: 'sonarqube-test'
    scannerMode: 'MSBuild'
    projectKey: 'project_key'
    projectName: 'Project Name'

- task: DotNetcoreCLI@2
  displayName: Build Net Core
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: SonarQubeAnalyze@4

- task: SonarQubePublish@4
  inputs:
    pollingTimeoutSec: '300'

- task: sonar-buildbreaker@8
  inputs:
    SonarQube: 'sonarqube-test'
2

Hey there.

So – it’s not possible to have two Quality Gates apply to a project. You could theoretically poll for some metric values and manually construct a Quality Gate through some scripting (comparing latest values to desired values), but I wouldn’t recommend it.

I would like to understand this more (and perhaps challenge it)

There are two ways to interpret this:

  1. You want to work towards getting developers to achieve 85% code coverage on their changes, who are currently only targeting 80%
  2. You want the overall codebase to eventually mature from 80% code coverage to 85%

By setting a stricter Quality Gate condition on New Code now (case #1), eventually the code coverage on your overall codebase will gradually increase and eventually allow you to set that same condition on Overall Code so it never drops below the new threshhold (case #2). This is our Clean As You Code philosophy in action, and typically all the “nudge” your developers need to improve the overall quality of the codebase over time.

3

Thank you for the reply Colin and even though it might not seem like it, it have sparked some ideas for an internal discussion regarding your suggestions :slight_smile:

The initial idea is to improve future code.
But eventually when mature enough start on handling technical debt.

I understand what you are getting at, but lets say you are a large enterprise with some people not used to do tests and having a high code coverage (code being at 50%-60% at best). Where as other teams might be significantly better and closer to 90-95%.

If we do not want to have 10-20 different quality gates due to maturity differences or stop production completely for those teams not mature, it would be nice to have a low quality gate but try to track and show the next level before implementing it.

Until now a low quality gate had been introduced, but people don’t improve as fast as expected meaning other teams a following the “lowest bar”. So the current “one gate” method does not work as indented.

We could of course apply a higher degree of QA, but to me that is more like a officer/police kind of position, which we do not wish for, however this may be necessary.

Long story short, I read that it is not possible.
So instead I would need to extract the scanner results manually and create a components with the future desired states outside of SonarQube.

That or create two+ projects per codebase or have someone enabling and guiding those teams with low scores.

Cheers again :slight_smile: