-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
Jenkins: 2.440.3
Coverage-Plugin: 1.14.0
Squish Coco: 4.3.1
I want to use the Coverage plug-in for Jenkins for a C++ project. In said project I use Squish Coco to generate a code coverage report in Cobertura format which is then fed to the recordCoverage step of the Coverage plugin.
In the project, there are several functions each containing several lambdas with the same signature (which is pretty common in C++, I suppose). Since those lambdas are also instrumented, they land up in the Cobertura file which, when being passed to the recordCoverage step in a Jenkins pipeline, causes an error of type:
java.lang.IllegalArgumentException: There is already a child [METHOD] calculate::[lambda][](int) <0> with the name calculate::[lambda][](int) in [CLASS] calculate <1, LINE: 100.00% (1/1)>
This already happens for example for the following function:
int calculate(int value) { auto plusTwo = [](int x) { return x + 2; }; auto timesTwo = [](int x){ return x * 2; }; return timesTwo(plusTwo(value)); }
When instrumented, tested, and converted to a Cobertura file, this creates the following snippet inside the latter:
<class name="calculate" filename="Calculate.cpp" lineRate="1.0" branch-rate="1.000000" complexity=""> <methods> <method name="calculate::[lambda]" signature="[](int)" line-rate="1.0" branch-rate="1.000000"> <lines> <line number="53" hits="3" branch="false"/> </lines> </method> <method> <method name="calculate::[lambda]" signature="[](int)" line-rate="1.0" branch-rate="1.000000"> <lines> <line number="54" hits="3" branch="false"/> </lines> </method> </methods> </class>
One should note that the only difference in the Cobertura file between both lambdas is their line number. This snippet supposedly causes the parser error which, in turn, causes the whole pipeline step to fail. This parsing error is quite unfortunate since such code with several lambdas in the same scope is by no means exotic or rare.
One can make the parser ignore this error by using the ignoreParsingErrors option of the recordCoverage step but this still causes two kinds of problems:
- The skipped parser errors are still written to the output which makes them hard to differentiate from actual hard errors.
- The generated Coverage report is still faulty since every lambda skipped by such a parsing error counts as "not covered" even if the Cobertura file says otherwise.
It would therefore be desirable to either have the parser fixed to not count this scenario as error or at least have an option (or adjust the existing one?) to work around this issue by at least still providing the correct metrics in the end.
- links to
We run into the same problem with Ruby and JavaScript code coverage. This used to work in the past but started failing when we upgraded the coverage plugin (1.6.0 -> 1.13.0) and deactivated the deprecated code coverage plugin (4.7.0).
Ruby
We are using the simplecov-cobertura formatter and the coverage report contains two classes with the same name:
Which causes the following error on Jenkins when recording the coverage:
I already commented on a related bug report for the project.
JavaScript
For our JavaScript tests we use the built in cobertura formatter from jest (`--coverage-reporters=cobertura`), which also doesn't care about unique name attributes:
Resulting in this error: