Strange issue with Quality Gate failing

I am using SonarQube version 8.6 (I know this is not latest and greatest). I have an strange issue where code was merged from a feature branch into the master (main) branch and when the happened SonarQube showed a failing quality gage on the master (main) branch. the reason for the failure is "New Major Issues > 0, New Critical Issues > 0). So what I did was I added “Lines of Code”, “Major Issues” and “Critical Issues” to Activity graph. I can’t show the the screenshot here, but here is the summary:

On July 15th (before the quality gate failure) I have:
3187 Lines of code
13 Major issues
9 Critical issues

On July 16th (after the code merge) I have:
3196 Lines of code
13 Major issues
9 Critical issues
Quality Gate : FAILED.

Given that the reason for the failure is "New Major Issues > 0, New Critical Issues > 0), I can’t see how this is possible since the count of Major and Critical issues is the same between the successful build and the failed build. What’s most interesting is the Maven logs say the quality gate failed because:

New critical issues: 8 > 0
New major issues: 13 > 0

I have no idea how these numbers were calculated. Thoughts?

Hi Michael,

Quality Gate represents the best way to implement the Clean as You Code concept by focusing on new code. (Quality Gates | SonarQube Docs)

By default, “New Code” is defined as code added or changed since the previous version. Meaning if you are refactoring your code, the refactored code is “New Code.”

By contrast, let’s define old code or legacy code. Personally, I like to think of this in the Robert C. Martin paradigm. He wrote “Clean Code” and “Working Effectively With Legacy Code.” Martin states in Working Effectively with Legacy Code, “Legacy Code is code without tests.”

Regardless if the code committed is designed to either

  • preserve existing behavior (by refactoring and testing Legacy Code effectively)
  • Or create an entirely new behavior,
    both are considered New Code by default to SonarQube.

The default quality gate called “Sonar Way” does not check for a reduction in the number of issues on old code because you need new code to create the changes to the old code.

“As long as your Quality gate is green, your releases will continue to improve.” - Clean as You Code | SonarQube Docs

Without being able to look at your quality profile used and the code changes, I can give an educated guess. The area in the code where the issues were, was changed enough to be considered new code but the issues did not disappear. Since new issues can’t be introduced then the Gate fails.

We have a few ways of measuring code, Issue Severity, Maintainability, Reliability, Security, etc. Each of those categories, analysis the code in different ways. Which could offer less noise than new issues introduced (aka New Major Issues > 0). You might want to look into that or you need to solve the Major and critical issues that already exist.

You can read more at these links:

Hope this Helps,

Thank you for the information. All this makes perfect sense. However, I still can’t figure out how the Quality Gate would fail neither the Major nor Critical issue counts changed from July 15th to July 16th. The only thing I know is the Quality Gate started to fail because when I hover over the little triangle icon on the activity page it says “New Major Issues > 0, New Critical Issues > 0” But that’s all in information I can get. I can’t see what SQ is considering to be new code and what the issues are.