Replacement for issue type count badges

SonarQube Server / Community Build Product Manager for a Day
1

We are in the process of upgrading to SonarQube 10.4 from a much older version (8.9 LTS). It appears some of the project badges are being deprecated and I’m hoping to get a replacement for our use case.

We have been using project badges in GitLab to provide our devs a snapshot of SonarQube metrics. Currently we display the reliability rating, security rating, and total number of code smells. This provides a good snapshot of the current state of the code so we can see where we may have opportunities to pay down tech debt.

In the latest version, the issue count badges are flagged as deprecated. I understand that there is a shift away from bugs/vulnerabilities/code smells to a more generic concept of “issues,” but I was hoping to see a badge that would display the total issue count for a project. I’ve considered the “Technical Debt” badge as a potential replacement, but the big drawback there is that external analyzers (e.g. Roslyn for C#) would not be accurately represented.

Can we get a new badge that just displays the total open issue count for a project?

6

Hi @bjmyers ,

Thank you for raising this. We don’t currently have a badge that covers what you need. I have raised this as a need internally. Is it sufficient to just have an open issue count, or do you need a more fine grained breakdown by the qualities like security/reliability/maintainability?

Best regards

John

8

Hi @john.clifton,

For my purposes, the open issue count would be sufficient. This badge would be used to supplement the existing security/reliability/maintainability rating badges (A-E) so having a total issue count in a single badge would be more compact.

That said - adding both the total issue count badge and the quality-breakdown badges would provide maximum flexibility for your user base. But if I had to pick one or the other, I’d prefer a “total open issues” badge.

Thanks,
BJ

1 Like
9

Thank you for coming back so quickly @bjmyers!

We’ll add this to the internal discussion.