I get what you are saying .. I just did not understand how if the QualtiyGate returns only a PASS/FAIL that you can interpret that to be UNSTABLE under certain circumstances. I do not want to see the options be PASS/UNSTABLE as that would have major repercussions.
They offer the option:
// Parameter indicates whether to set pipeline to UNSTABLE if Quality Gate fails
// true = set pipeline to UNSTABLE, false = don't
waitForQualityGate abortPipeline: true
I am simply suggesting you have an alternative to that, which is to have different Quality Gates configured in SonarQube.
As noted in the SonarSource tracker, MMF-473 Simplify the definition of Quality Gate, the simplification (/dumbing down) of the Quality Gate has been on the roadmap for 5 years. I did not even know there used to a WARNING state, which could have mapped relatively cleanly to UNSTABLE request.
I have no relation to the sonar plugin, other than as a user of it. We have well over 2000 projects under analysis across multiple Orgs w/1000's of Dev, we are now a user of SonarQube Enterprise. I agree SonarSource is rather/very opinionated, both in terms of pass/fail and in assumptions on how development happens and how you can use their tools, which don't necessarily integrate well with non-greenfield operations. I don't see them changing course (Immovable object).
As for Jenkins glossary, I would not rely on that as definitive gospel. The explanation even says, "for example".
If the actions of another plugin (sonar) don't align with the example given, that is a design decision the makers of the plugin have implemented (with an escape hatch); they decided the QualtiyGate FAIL should generally FAIL the build, and that makes sense. You have the ability to alter the FAIL criteria in SonarQube, otherwise if a user looked in SQ, they'd see it FAILS but the pipeline might continue with the failed artifact. That is is risky.
Jenkins (Hudson) originated primarily as as a tool to build / CI Maven applications. JUnit is historically a universal step in the testing of maven projects and is used throughout the docs as an example (eg: here , here, here).
The JUnit plugin is a publisher (post-build) step, while SonarScanner is a build step for analysis with a QualityGate step, which is also a build step.
That's just my 2 cents. Thanks.