Coverage/tech debt chart is empty

SonarQube Server / Community Build
,
1
  • SonarQube Enterprise Edition v2025.1 (102418)

I used to be able to see a chart of coverage for new code in my SonarQube project, but now it’s empty:

image
image1401×608 51.1 KB

This is despite the coverage data being uploaded to SonarQube from the Azure DevOps pipelines; as you can see on the left-hand-side of the chart, there is coverage data for both new and overall code. The chart above is for the master branch, but the same is true of other branches and PRs too. There is a valid chart for a since deleted branch, but very little (if anything?) has changed since that branch, with respect to SonarQube config or treatment of coverage files. I can still see this chart fine in another SQ project though, so it seems unlikely this is a new bug in SQ server.

Does anyone have any ideas why this chart might be empty even though coverage data is being uploaded?

2

Hi,

This isn’t just a chart of coverage. It’s coverage (y-axis) vs technical debt (x-axis) with file size (bubble size) and Reliability/Security rating (bubble color). It’s likely that the absence of any one of these could cause the graph to fail. Do you have any browser console errors?

And does this fail for all projects in your instance or just the one?

 
Thx,
Ann

3

Ok thanks Ann. No, it only seems to be in this one project AFAIK. I only see one browser console error, but I don’t think it’s relevant (Error: attribute width: A negative value is not valid. (“-100”)) as it also occurs in the other branch where the chart does display ok. I did do a run the other day with verbose logging (sonar.verbose=true) but there were no obvious errors in there. If you could tell me what to look for in the log that would help, please.

4

Hi,

Can you verify that the four metrics are all populated for this project? And what languages are we talking about here?

 
Thx,
Ann

5

This project is mainly C++ but also a tiny bit of Python. All 4 metrics appear to be populated in that you can see data for Coverage, Size, Reliability and Security on the side-bar. If you have another way of verifying those metrics are being received, pls let me know.

6

Hi,

Could you share that? TBH, I’m not sure how much it will help, but I’m grasping at straws.

 
Thx,
Ann

7

Many thanks! I’ve sent it to you privately.

9

Hi,

Nothing is jumping out at me from your log file. I’m going to call for help on this one.

 
Ann

1 Like
11

Hey @cacti77!

While you’re browsing your DevTools you should see a Web API call that looks like this:

https://SONARQUBE_URL/api/measures/component_tree?s=metric&metricSort=ncloc&asc=false&ps=500&p=1&component=PROJECT_KEY&metricKeys=software_quality_maintainability_remediation_effort%2Ccoverage%2Cncloc%2Csoftware_quality_reliability_rating%2Csoftware_quality_security_rating&strategy=leaves

{
  "paging": {
    "pageIndex": 1,
    "pageSize": 500,
    "total": 1043
  },
  "baseComponent": {
    "key": "PROJECT_KEY",
    "name": "PROJECT_NAME",
    "qualifier": "TRK",
    "measures": []
  },
  "components": [
    {
      "key": "PROJECT_KEY:FILE_PATH",
      "name": "FILE_NAME,
      "qualifier": "FIL",
      "path": "FILE_PATH",
      "language": "cpp",
      "measures": [
        {
          "metric": "coverage",
          "value": "97.6",
          "bestValue": false
        },
        {
          "metric": "ncloc",
          "value": "3284"
        },
        {
          "metric": "software_quality_reliability_rating",
          "value": "1.0",
          "bestValue": true
        },
        {
          "metric": "software_quality_security_rating",
          "value": "1.0",
          "bestValue": true
        }
      ]
    },
...

What does the API output look like for you? Do you have all 4 metrics being calculated? This is the API call driving the chart data.

1 Like
13

Thanks @Colin! The response payload is interesting. It seems 3 of the 4 metrics are present for all 82 files listed under “components”. But the “coverage” metric is only present for 45 of them.

Eye-balling through the files for which the coverage metric is missing, they appear to mostly match the file patterns listed in sonar.coverage.exclusions of our sonar-project.properties file, plus at least one .h file.

sonar.coverage.exclusions=**/test/*.cpp,src/interface/lib/dgapi.cpp

As you’d expect, we don’t want to include test files in coverage measurements.

14

@Colin Now I’m a bit confused as it appears there are actually 5, not 4 metrics!

Luckily, there was an older branch on the same project for which the coverage/tech debt chart is displayed properly in the SQ UI. So I compared the API’s response payload for the branch with the correctly displayed chart to that for the branch with the empty chart.

The count of the 4 metrics we already discussed is the same for both branches (i.e., 45 for coverage, 82 each for ncloc, software_quality_reliability_rating and software_quality_security_rating). But in the old branch, which displays successfully, there are also 73 counts of a 5th metric - software_quality_maintainability_remediation_effort - of which there are none for the branch with the empty chart.

So what is needed for software_quality_maintainability_remediation_effort to be calculated?

15

Hi @cacti77,

That’s an interesting idea, but the presence of that metric shouldn’t impact whether or not a bubble appears on the chart.

To explore further, have you tried viewing this in a different browser? Sometimes that can help identify if the issue is browser-specific.

16

OK.

The issue isn’t browser-specific. Remember I can still see charts for other projects or even another branch in the same project in Google Chrome. I also tested in MS Edge, and all the charts look the same there for the same project/branch combos.

17

Okay rereading your previous post, I realized I completely missed this.

This indicates to me that files in that branch have maintainability issues (code smells) being raised, while in the new branch there aren’t.

And what do you know, I can reproduce this on an internal project that has some issues, but no maintainability issues.

What I forgot earlier is that Technical Debt in SonarQube is the sum of remediation effort for issues related to maintainability only, even though other issue types are assigned a remediation effort.

So I think what’s going on here is that you have no Maintainability issues in this branch. You should be able to confirm this by opening up the Maintainability section of your measures page.

Now the question is should you have no maintainability issues, or is something wrong? Maybe your code is just really tidy. :slight_smile: But I would move on from comparing charts to comparing the analysis results – are you seeing the issues you expect to see?

1 Like
18

In all the charts I’m comparing, there are no maintainability issues for the new code but - you’re right @Colin - the charts that are empty have no issues for overall code too! There should be > 5800 issues overall (I’m ashamed to admit); so that’s not right.

I don’t fully understand what’s happening, but I now suspect there’s nothing wrong with SQ or with our project. It’s more likely an artifact of recent events…

We recently reorganised the layout of the source and test code in the repo. That in turn caused the Quality Gate to fail due to ‘new issues’, poor coverage and code duplication. Since the code itself hadn’t really changed, we worked around this by bulk-accepting the so-called ‘new’ issues, and also by updating sonar.projectVersion to refer to the git tag immediately after the reorganisation.

So the master branch and the new branch (which is very similar to master) should have no new maintainability issues because nothing’s changed; but the old branch that was still new relative to the previous release had loads of issues and hence a graph.

It’s confusing that the top-right of each chart always refers to ‘new code’ whereas the chart itself appears to show data for the overall code rather than new code.

I’m also not sure how the chart will ever get populated again since the Quality Gate blocks new issues.

19

Hey @cacti77

Hm. I would have hoped that file move detection would have kicked in here, although it’s not perfect. Did your SCM detect that these files were moved rather than deleted/recreated?

Another option would have been (and perhaps still is) to start with a new project, perform a first scan (those issues all become part of the overall code) and then the new code (and issues) would be anything introduced after that first scan. You would lose measure history, but you’ve already lost issue history (issues marked as FP/WF) if as you say, all issues have been reopened as new.

Bulk accepting is a pretty unfortunate workaround, since they are now “closed”.

In the course of upgrading your SQ instance, you may find issues on overall code because of new rules / improved rules that raise issues that get backdated (so they don’t fall into the new code period).

20

Did your SCM detect that these files were moved rather than deleted/recreated?

Yes, but sadly SQ didn’t detect this.

They’re still visible under accepted issues in overall code, and we also bulk tagged them with the id of a ticket to address them. So they’re not lost forever.

Ok.

So to sum up, please correct me if I’m wrong on any of this:

  1. The empty coverage/tech debt chart is not because of a bug in SQ or a mis-configuration of my project.
  2. The chart can be empty if any of those 4 metrics are completely missing, or if there are no maintainability-related issues in new code.

But in another project I have maintainability issues in overall code, but none in new code, yet the chart is populated with bubbles, and the light blue rectangle to the top right of the chart definitely refers to new code.

So does the chart refer to new code or overall code? It would be really helpful to have a help link from that chart to some docs that explain how to interpret that chart and explain when it might be empty. (I do see you define tech debt here though.)

22

Hey @cacti77

The chart refers to Overall Code – so I agree it’s confusing you see the New Code in the light blue rectangle (which I think is meant to be just… information, not relevant to the chart being shown).

In any case, I’ve passed this feedback onto our PMs.

1 Like
23

Great, thanks for confirming that! Yes, that rectangle should definitely be changed to refer to Overall Code instead IMO. Thanks for passing this on.

25

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.