Best and simplest approach there would be to leverage the default (and recommended) Quality Gate conditions: https://next.sonarqube.com/sonarqube/quality_gates/show/30 (i.e. making sure that ratings on new code are pristine).
With respect to your ‘must-decrease’ policy:
I’d like to fail the QG anytime a new analysis is run and the total number of issues hasn’t decreased.
That’s a bit harsh, and is not doable with Quality Gate conditions out-of-the-box. I recommend you read about the recommended methodology: Fixing the Water Leak . And take the time to think about the perverse aspect of what you have in mind: I, as a developer, work on this project containing 215 issues, and implement a brand new Java class, independent from all other legacy code. If your policy was in place, then even if my code was ‘impeccable’ (no rule violated), then my changeset would be rejected because I still don’t decrease the number of overall issues. I lose confidence/sympathy towards this tool, and will find ways to cheat around it (or quickly get my change validated by fixing one of 215 issues without thinking much of it)