Quality Gate + Short Lived Branches

[ganncamp (G Ann Campbell)]

Hi,

We’ve got a slow-moving, but on-going initiative to embed relevant bits of documentation in the UI. You’ve made me realize this is a good candidate, so I’m going to see what I can get added for 7.5. Hopefully by 7.6 we’ll have real quality gates (no promises!) and this becomes moot.

 
Ann

[tokkov (Joe Swanson)]

@ganncamp

When “Confirm”, “Resolved as False Positive” or “Won’t Fix” actions are performed on issues in SonarQube UI, the status of the PR is updated accordingly. This means, if you want to get a green status on the PR, you can either fix the issues for real or “Confirm” , “Resolved as False Positive” or “Won’t Fix” any remaining issues available on the PR.

The down side of this particular approach is that it actually generates a significant amount of churn in shops with fully/heavily automated CI/CD systems. The reason I found this post to begin with was because I was trying to resolve issues with Jenkins failing jobs because the build is failing due to the quality gates. So the reality of my situation is that developers push a commit, jenkins kicks off the build pipeline, sonarqube fails the quality gate because someone has an informational issue in the code (that would have been allowed to leak by policy, not manual exception), now a developer has to go into sonar and see what’s up (which they don’t have to do normally because they get the reports linked through IntelliJ and may not actually have access to sonar since there is usually no need), mark the items appropriately, and then trigger a new build so that the quality gate can pass.

I appreciate that there is a work around for the issue. It is unfortunate that it is a manual work around that impedes automation and policy enforcement, and diverts resources from positive business value areas. It just seemed like a significant step backwards for such a wonderful product.

[ganncamp (G Ann Campbell)]

Hi,

Just to clarify

@tokkov

mark the items appropriately, and then trigger a new build so that the quality gate can pass.

The quality gate flips to passing as soon as you do something with the last Open issue.

@tokkov

trying to resolve issues with Jenkins failing jobs because the build is failing due to the quality gates

If your problem is not the quality gate but the build… well, we’ve said for a long time that breaking the build because of quality issues isn’t the best strategy. We nonetheless added webhook notifications so you can notify external systems of your project’s QG status. In addition, we fire the webhook when manual issue changes flip the QG status.

@tokkov

It just seemed like a significant step backwards for such a wonderful product.

Thanks. I think.
Just to repeat one more time, we recognize this is sub-optimal and plan to get to the point of offering real, user-controlled quality gates on PRs and SLBs. We’ve delivered interim stages of the product because we believe in delivering, rather than waiting until we’ve got a theoretically “feature-complete” version.

 
Ann

[darth_pepe]

Agreed, i would like to delete sq right now -__- our checks are worth nothing right now

[Alex_Denton]

Is there some where I can vote this feature up? This would be a big win for my team. I would happily provide any feedback to explain my use case.

[ganncamp (G Ann Campbell)]

This feature is currently in development @Alex_Denton and should be included in 7.7.

 
Ann

[Alex_Denton]

Glad to hear it! Keep up the good work.

[philippneugebauer]

@ganncamp I couldn’t find this feature on Sonarcloud yet and also the documentation still states about this limitation. Was this part of 7.7 or is it delayed? And what is the plan about this feature then?