I would like a tightening quality gate

[StingyJack (Andrew Stanton)]

One that requires the same or better with every commit.

If there are currently 15 code smells, a 16th can’t be added. If coverage is 75% it can’t go below that. If the next commit takes the coverage to 77 percent with 13 smells, those become the new thresholds.

[cwata (Chris)]

Hi Andrew,

just playing devil’s advocate here: why would you want to do this? I could see some value in forcing your code to have an ever-increasing quality, but what are the benefits of this when you could enforce a high threshold from the beginning?

[StingyJack (Andrew Stanton)]

Because it looks bad from the beginning if you do it that way. A tightening gate would let us meet some minimum level of quality and then only get better from there. And wouldn’t let it slide to worse. (This last part would help with the 20 lines of code minimum nonsense that’s in sonar cloud)

[Colin]

Hey @StingyJack

You might want to chime in on this existing thread about ratcheting Quality Gates

Ratcheting Quality Gate conditions: Fail Quality Gate if coverage decreases from last analysis

SonarQube version: 7.9.1 LTS sonar.leak.period = previous_version We want our Quality Gate to fail if coverage decreases during the leak period, regardless of whether it is still above our threshold of 70% (Example: If coverage from last analysis was 75%, quality gate should fail if coverage on next analysis is 74.9% or lower). In older versions of SonarQube this could be accomplished by using the condition “Coverage, Delta since last analysis, less than, 0”. Is there a way to do that with t…

(We’re not brushing you off – Ann and I both support this idea, and want to make sure the reports are consolidated!)

[StingyJack (Andrew Stanton)]

@Colin

(We’re not brushing you off – Ann and I both support this idea, and want to make sure the reports are consolidated!)

I dont take it as a brush off. I’m fine with reducing duplication. I did search before posting, but didnt think of using “Ratcheting”