When you update a language plugin and it has new rules or updated ones, next analyses might discover critical or blocker on code that is not part of the leak. Still, you certainly don't want to ship the code into production when you know that such bugs or vulnerabilities exist - even in untouched code.
Also, without having the possibility to force development teams to fix those critical and blocker new bugs or vulnerabilities, it's virtually impossible to put in place a governance strategy to gradually raise the security and reliability ratings on your application portfolio.
For those reasons, it must be possible to specify in a quality gate that:
- Reliability Rating must be better than C
- Security Rating must be better than C
For this to work:
- The Quality Gate page must be updated to make it possible to set condition on ratings
- Like this is currently possible in the "Measures" page
- In terms of UX, we should pay attention to the operators (<, >, <=, >=) that can be misleading when we talk about ratings
- The following rating metrics should be available on that page:
- Security Rating
- Reliability Rating
- Maintainability Rating (<= adding this one will allow to get rid of the "Effort to reach Maintainability Rating" that was a trick to enforce "A")
- Compute Engine must handle those new kind of conditions
- The project home page must be correctly displayed when quality gate fails because of rating