Template for a good new topic, formatted with Markdown:
ALM used: GitHub
CI system used: GitHub Actions
Scanner command used: any
Languages of the repository: any
Error observed: QUALITY GATE STATUS: FAILED
Some time around 13:00 UTC today it seems like Quality Gate behaviour changed when there are no conditions. Instead of always passing, they now always fail.
We have a number of repositories that have been using an empty quality gate, as, while onboarding onto Sonarqube Cloud and tidying things up, we don’t want strict quality gates but do want to make our builds wait so that we can post PR feedback from a custom internal bot.
It seems that suddenly empty quality gates now always fail, which caught us by surprise. We have worked around it by adding a condition which will be impossible to break (a ridiculously large number of issues). However we’d like to know if this was, as it seems, a change at Sonarqube Cloud’s end and if it will be a lasting one.
This is indeed a bug. We’ll activate a feature flag to restore functionality for now and will work on a proper fix soon.
Also, I noticed the empty Quality Gate! We usually prevent users from doing that—I actually struggled to reproduce it myself (had to create a Quality Gate with a condition, assign it to a project, and then remove the condition). Could you share more about your use case for SQC in this setup? I’m curious to learn the context.
I’ll check with the team who did initial setup if we wrote anything up on the decision to use an empty quality gate. I think my recollection above is roughly right but want to double check. Will hopefully get back to you on that shortly.
Would you be able to give it a try now? Funny story, the feature flag we flipped doesn’t affect our own organization, so it’s a bit complicated to test it ourselves.
We’ve tested using a new blank quality gate, and the build succeeded as expected - thanks.
As for the reason we have an empty quality gate, and use it by default: we’ve been onboarding a large number of repos to Sonarqube this summer, and prefer to monitor the code quality stats rather than block them in CI. As teams sort issues out they’re gradually opting in to normal blocking quality gates, but we wanted to make it as easy as possible for them to get started without ‘judgement’ for existing issues!
We usually prevent users from doing that—I actually struggled to reproduce it myself (had to create a Quality Gate with a condition, assign it to a project, and then remove the condition). Could you share more about your use case for SQC in this setup? I’m curious to learn the context.