Uploading artifacts...
coverage/jest/cobertura-coverage.xml: found 1 matching files and directories
Uploading artifacts as "cobertura" to coordinator... ok id=**** responseStatus=201 Created token=****
When coverage is dropping there is no visualisation for it, the same is when coverage increases.
If you can upload a bit of the cobertura-coverage.xml file or provide a link to the project if public I can take a look. I did want to call out there’s a known limitation that the parser does not support the <source> element. It is assumed that the filename of a class element contains the full path relative to the project root.
That helps @orthodoz - If the git root of your project is “project-folder” the feature should be working as intended. If it is not you’ll need get the path more clearly defined.
@orthodoz - i just want to confirm you are looking at the changes tab on the MR as that is where this information appears? Here’s an example from the GitLab project.
Beyond that i’m stumped but I’ve asked the team to take a look to make sure i’m not missing something.
@jheimbuck_gl - I am facing a similar issue on a self-hosted GitLab instance (version 13.2.4). I am essentially using the gradle example configuration from the code coverage example documentation. Like @orthodoz I see that the cobertura-coverage.xml file is uploaded and I can download it from the pipeline (although it is cobertura-coverage.xml.gz at that point). In my cobertura-coverage.xml file, the source tag is set to src/main/java and each of the filename attributes on the class elements also starts with src/main/java.
I tried to search through some of the source code and debug a little, but I haven’t really done any work with Vue or Ruby, so progress is a little slow. On the browser side, stepping through some of the JS code, it seems that endpointCoverage is not set and therefore fetchCoverageFiles is never called for me, but I have not been able to trace that back to what condition is missing on the backend.
Here are a few things I have tried without success:
gradle example exactly as shown in the documentation
change the XML file name to match the “default” name shown in the ruby code
upload the XML file as a plain artifact and a report artifact
running in a branch pipeline vs merge (detached) pipeline
both the source and target branches having a coverage report
Below is a snippet from the logs of the job uploading the artifact:
$ python3 /opt/cover2cover.py build/jacoco/jacoco.xml src/main/java > build/cobertura-coverage.xml
$ python3 /opt/source2filename.py build/cobertura-coverage.xml
src/main/java
Uploading artifacts for successful job
Uploading artifacts...
build/cobertura-coverage.xml: found 1 matching files and directories
Uploading artifacts as "cobertura" to coordinator... ok id=5413 responseStatus=201 Created token=******
Job succeeded
Unfortunately, I also cannot provide access to my project as it is proprietary, but I would be happy to provide what additional information I can.
I solved my problem. It turns out the 13.2.4 documentation mentions enabling the :coverage_report_view feature flag, but the newer documentation I was looking at does not. I enabled the feature flag and it started working!
We have a similar setup with the same python job converting jacoco → cobertura. We also have the feature active but still cannot see the coverage being visualised?
Here ‘./apm-fns/apm-fns-swish/apm-fns-swish-app/src/main/java/com/fiserv/apm/fns/swish/app/model/response/ReturnAndVoidAppResponse.java’ is the full file path from the repository root.
Things look good to me based on your post. There could be a problem similar to what was reported in this issue but I haven’t had a chance to dig into it to be sure. Some users also note it just takes some time to parse the file if very large.
If you expand the lines shown do any lines include the visualization?
I have checked the other lines and older merge requests - nothing visual there either. Also, I checked the html source: <div class="diff-td line-coverage left-side new"></div>
I guess this means that coverage is successfully turned on. I will check the pointing to the root of the repository - maybe the ~60 entries are confusing processing. But since we are on 13.9 this should be an issue anymore, right?
I worked quite hard on getting coverage to work and currently publish the jacoco report on gitlab pages for master builds. That’s better than nothing, but doesn’t help with code reviewing. Having the code tested is really important for our definition of done - and currently too difficult to identify.
Was there ever any resolution to this? We have the same problem here- no code coverage for Cobertura reports. I’ve tried everything, from fixing the paths in the cobertura.xml to ensuring that the coverage_report_view is enabled.
