Inline Code Coverage Report parsing fails on multiple source directories
Summary
In the event of multiple <source>
directives in cobertura.xml, the coverage report fails to parse completely (as it tries to do .each()
over a String.
Furthermore, the actual source
directory values aren't read or utilized, so Java-based projects are unable to use inline code coverage.
These are bugs affecting the implementation of #3708 (closed).
We should handle these exceptions gracefully and document this limitation on the inline-code-coverage page.
Steps to reproduce
Attempt to parse a Cobertura file with multiple source directories. This fails instantly. Example below.
<coverage branch-rate="0.656028368794" complexity="377.0" line-rate="0.80602006689" timestamp="1587504897">
<sources>
<source>project-api/src/main/java</source>
<source>project-impl/src/main/java</source>
</sources>
<packages>
<package branch-rate="0.5" complexity="13.0" line-rate="0.594594594595" name="com.d2dx.v1.model">
<classes>
<class branch-rate="0.0" complexity="1.0" filename="com/d2dx/v1/model/Error.java" line-rate="0.0" name="com.d2dx.v1.model.Error">
<methods>
<method branch-rate="0.0" complexity="1.0" line-rate="0.0" name="of" signature="(Lcom/d2dx/v1/model/Error$Error;)Lcom/d2dx/v1/model/Error;">
<lines>
<line branch="false" hits="2" number="1"/>
<line branch="false" hits="0" number="2"/>
</lines>
</method>
</methods>
</class>
</classes>
</package>
</packages>
</coverage>
Furthermore, in a Maven project, the standard layout will be project_dir
/src/main/java
/package/of/Class.java
. In Cobertura XML this translates to
<coverage>
<sources><source>src/main/java</source></sources>
<classes><class filename="package/of/Class.java"></class></classes>
</coverage>
Since GitLab completely ignores the source
directive, the coverage_reports.json
output of GitLab will report zero (0) covered files. This is because GitLab has indexed the file package/of/Class.java
but the filename in the repository is src/main/java/package/of/Class.java
.
Both of these scenarios are encompassed in the sample XML above.
Example Project
The feature isn't enabled on GitLab.com and therefore cannot be reproduced on GitLab.com. I can extract a sample if desired, but I need to install another private GitLab to reproduce so I'd rather not do it if the above report is sufficient.
What is the current bug behavior?
If multiple source entries are found, coverage_reports.json
will fail to load (with a 400, if I recall correctly).
If it's used on a Java project, coverage_reports.json
will report 0 files have coverage due to the filename/path mismatch.
What is the expected correct behavior?
coverage_reports.json
should not fail to load for cobertura.xml with multiple <source>
entries.
coverage-reports.json
should correctly point out the path for Java projects.
Possible fixes
-
cobertura.rb
needs to differentiate between Array and String entries of source key -
coverage_reports.rb
should match up files with sourcepaths - We should handle these exceptions gracefully and document this limitation on the inline-code-coverage page.
Apart from the spec (just playing around there really) the code in cobertura.rb
and coverage_reports.rb
is the workaround we are currently using for the issue. As noted in the diff, I expect you probably want a solution using the pick
method, but I'm not fluent enough in Ruby to make that workaround.