Test coverage visualization not work

How to Use GitLab Upgrade
1

hello,
I config test coverage visualization according to Maven example in Test coverage visualization | GitLab, but when the pipeline tasks finished, there is still no test coverage info on the merge request diff page.
My GitLab version is “GitLab Enterprise Edition 13.6.7-ee”, and content in cobertura.xml is like the following, because it is a private project, so I replace some key info.

	<coverage timestamp="1626956500.575" line-rate="0.18101287702013655" branch-rate="0.04351694572514762" complexity="13964.0">
  <sources>
    <source>/builds/a/b/c/d-common/src/main/java/</source>
    <source>/builds/a/b/c/d-dao/src/main/java/</source>
    <source>/builds/a/b/c/d-portal/src/main/java/</source>
    <source>/builds/a/b/c/d-alarm/src/main/java/</source>
  </sources>
  <packages>
    <package name="com.a.b.c.configurer" line-rate="0.772020725388601" branch-rate="0.425" complexity="52.0">
      <classes>
        <class name="com.a.b.c.configurer.SchedulerConfig$1" filename="/builds/a/b/c/d-common/src/main/java//com/a/di/c/configurer/SchedulerConfig.java" line-rate="1.0" branch-rate="1.0" complexity="3.0">
          <methods>
            <method name="&lt;init&gt;" signature="(Lcom/a/di/c/configurer/SchedulerConfig;Ljava/util/concurrent/ScheduledThreadPoolExecutor;)V" line-rate="1.0" branch-rate="0.0" complexity="1.0">
              <lines>
                <line number="46" hits="1" branch="false"/>
              </lines>
            </method>

is there any issue with my cobertura.xml? Thank you in advance for any help.

2

@bingbing.wang - Welcome to the forum and thanks for the post!

Unfortunately there is not support for multiple source directories today. There is an open issue for this capability but it is not currently scheduled.

If the filename has the full path to the source, which it appears yours does but with an extra / the feature should work. Hopefully this helps!

-James H, GitLab Product Manager, Verify:Testing

3

@jheimbuck_gl Thanks for your reply, will the feature of test coverage visualization be turned on by default in GitLab Enterprise Edition 13.6.7-ee?

4

@bingbing.wang - Yep it was enabled by default starting in 13.5. The Version History in the GitLab docs will usually have this information for a feature.

-James H, GitLab Product Manager, Verify:Testing

5

so weird, still not work

6

There have been several bug fixes made, most recently in 13.9, as well as the automatic class path correction that was not enabled by default until the 13.9 milestone as well.

There have been several threads in this forum that may also help you in troubleshooting any further issues. If you’re on a paid support plan I would suggest opening a support ticket as well.

I hope this helps!

-James H, GitLab Product Manager, Verify:Testing

7

Thanks, @jheimbuck_gl, I refer to another thread and change my code as following, and it works.

	<coverage timestamp="1626956500.575" line-rate="0.18101287702013655" branch-rate="0.04351694572514762" complexity="13964.0">
  <sources>
    <source>d-common/src/main/java/</source>
    <source>d-dao/src/main/java/</source>
    <source>d-portal/src/main/java/</source>
    <source>d-alarm/src/main/java/</source>
  </sources>
  <packages>
    <package name="com.a.b.c.configurer" line-rate="0.772020725388601" branch-rate="0.425" complexity="52.0">
      <classes>
        <class name="com.a.b.c.configurer.SchedulerConfig$1" filename="d-common/src/main/java//com/a/di/c/configurer/SchedulerConfig.java" line-rate="1.0" branch-rate="1.0" complexity="3.0">
          <methods>
            <method name="&lt;init&gt;" signature="(Lcom/a/di/c/configurer/SchedulerConfig;Ljava/util/concurrent/ScheduledThreadPoolExecutor;)V" line-rate="1.0" branch-rate="0.0" complexity="1.0">
              <lines>
                <line number="46" hits="1" branch="false"/>
              </lines>
            </method>
1 Like
8

Hi,
Sorry for bothering you with this but I have the same issue as you reported.
Do I understand correctly that what what fixed it for you is to use full file path relative to the project root folder in the filename attribute? If so, how did you make cobertura.xml to be generated like that?

1 Like
9

I too am having a difficult time giving up on getting this to work (Gitlab 15.6 CE Omnibus install). And seeing the latest post got me inspired to try again. So, I have the elements as paths relative to the project root - eg. a/b/c if a is a top-level directory in the project/repo. And I have python source files that show up as elements and since a/b/c/pkg/mod1.py is a valid file path in the repo & mod1.py is modified in the commit that triggers the pipeline, I was hoping to see some coverage visualization in the MR “Changes” view. But no such luck.

I then downloaded from the job that created the *-coverage.xml (actually 3 of them are found via artifacts:reports:coverage_report paths in my .gitlab-ci.yml). So per the docs, all 3 are uploaded. When I download the cobertura-coverage.xml.gz from the pipeline’s artifacts, I notice that the resulting XML file has 3 prologs (ie. <?xml version="1.0" ?>) each with the 1 element. Does this possibly affect the Gitlab visualization parser & thus, could be the root cause for why the visualization doesn’t render?

Firefox 111.0.1 chokes on loading the cobertura-coverage.xml with 3 prologs so perhaps? And the file still needs a root element with cardinality of 1 (firefox also complains if there is a 2nd root element - the 2nd ). I read the “How test coverage visualization works” section as being that my use case is supported: multiple Cobertura files can be specified, uploaded and no mention that I need to manipulate the XML files (ie. I could combine them in a script, create a root element with 1 or more elements but I don’t know if the Gitlab parser will process that ok. However, I read the DTD at cobertura/coverage-04.dtd at master · cobertura/cobertura · GitHub to indicate only 1 element is allowed (no so no explicit root element).

The docs for artifacts:reports:coverage_report indicates only 1 report per job. I read this as only 1 such block in the .gitlab-ci.yml but that the path value can contain wildcards so that multiple xml files might be uploaded for the 1 report definition. Have I misunderstood? And that only 1 XML file can be upload despite the presence of “files” in the same doc section and the “including wildcard paths”…“combines it together” documentation.

Any suggestions to the correct general approach? Not knowing what the parser is doing, I thought I’d ask…MTIA for any feedback.

additional info: long after (hours) the pipeline associated with the MR completes, I go to the specific MR URL, once the overview page loads I bring up Chrome’s dev tools, network view to watch requests. I then select the “Changes” view, there is series of requests, one of which is https://gitlab.our-FQDN/org-name/proj-name/-/merge_requests/49/coverage_reports.json. But the response is minimal:

{"files":{}}

Searching through the *.log files under /var/log/gitlab/ modified today, i do see what appears to be a successful upload of the coverage_report artifact:

{"severity":"INFO","time":"2023-04-06T18:38:08.109Z","correlation_id":"01GXBXS5N1C62WX6925QMPXPV2","project_id":5,"pipeline_id":1030,"pipeline_artifact_id":64,"message":"Created code coverage for pipeline."}

That was the time of today’s only pipeline completing so it appears, well, correlated :slight_smile:

Now the big question is, what causes that API response to have an empty “files” object? XML Parsing error?