Feature Req: add exact coverage value, with virtually infinite precision into some hidden field of JSON and SVG for future comparisons about jacoco-badge-generator HOT 10 CLOSED

Validated the feature:

One-liner change:

 public class OrchestratorApplication {
 
     public static void main(String[] args) {
+        System.out.println(100500);
         SpringApplication.run(OrchestratorApplication.class, args);
     }
 

which is, of course, not covered by the test, yields:

Coverage decreased from 64.44058976582826 to 64.39869989165764
Failing the workflow run.

indeed, the comparison was done between the summary files, and 0.05% difference was caught successfully

QA: Passed

Alex

from jacoco-badge-generator.

Are you requesting an option to round instead of truncating? For example, right now 89.85 will truncate to one decimal as 89.8 whereas rounding we'd end up with 89.9. Or do you want an input to control number of decimal places?

from jacoco-badge-generator.

What I'm requesting is to add configurably more digits. Like, if we have this coverage reported: 23.55991131279494%, then, depending on the configuration, we'll see in the badge:

rounding: 0 => 24%
rounding: 1 => 23.6%
rounding: 2 => 23.56%
rounding: 3 => 23.560%
rounding: 4 => 23.5599%
rounding: 5 => 23.55991%
rounding: 6 => 23.559911%
rounding: 7 => 23.5599113%

Why it is important - is that we already have 100000 lines of the code in the project, and we'd like to catch the difference in the single line coverage, which means we need at least precision of 4 digits after decimal point, like 23.5599

Oh, yes, let me explain the full use case.

We build in main branch and save the coverage JSON file to some secure location as a reference baseline, and then for every build of PR, we fetch that baseline, and feed it to the coverage plugin, together with the jacoco report, so that it verifies if the coverage has declined. Hence, we rely on the precision of numbers in the JSON files.

from jacoco-badge-generator.

I see. There are actually two changes here (both doable) and your example use case gives me an idea for a third that may actually better fit (either by itself or in addition to) your use case.

First, right now the precision in the percentages is 1 decimal place. So one of the changes would be a configurable precision.

Second, currently the displayed coverage is truncated rather than rounded. The rationale is to avoid coverage less than some target minimum from appearing to meet the target minimum. Also to prevent something like 99.99% from showing as 100%. So an additional change would be to add an option to choose rounding rather than truncation.

A third possible change I see from your use case relates to how the action currently gets the prior coverage for use in the feature that compares current coverage to old for use in failing workflows if coverage declined. Currently, it relies on the displayed coverage which has been truncated. It should be possible to actually store the computed percentage, as is, in the badge or JSON for use by that feature. E.g. in the JSON as an extra field or in the SVG as a comment or something similar that is not rendered. In combination with the configurable precision, you'd be able to display in badge at one precision but use full floating-point precision in the decreased coverage check.

from jacoco-badge-generator.

Hello, Vincent.

Thanks for dissecting and analyzing my request and understanding the problem.

Indeed the third option would do the best job for my case. Requirement for the rounding - maybe we can drop it, as truncating seems to be a smarter choice. The change of the display precision is not required anymore as soon as there is an extra field in the JSON (not rendered) with an exact number.

Renamed the feature request, to narrow down the scope only to the third option - extra field.

We'll need also to figure out how shields.io reacts to that extra field. So far, what I see is that when I feed this json:
{
"color": "#e05d44",
"label": "branches",
"message": "9.2%",
"schemaVersion": 1,
"extrafield": 3.141592653589793238462643383279502884197169399375105820974944592307816406286
}

the shields.io draws a gray badge, saying "invalid properties: extrafield"

All above potentially means, that we need some external container JSON for coverage statistics, to be stored outside of JSON files. One extra JSON file, which includes both line and branch coverage, maybe?

Alex

from jacoco-badge-generator.

If extra fields cause a validation issue with shields, then your idea of an additional JSON file sounds like the way to go. I'll add an input to control whether it is generated so users don't get surprised by an unexpected additional file.

from jacoco-badge-generator.

@alex-schwartzman-at-stratify I just released an update for this, v2.5.0. It is disabled by default. Use generate-summary: true to enable. You can change the filename with summary-filename if you don't like the default coverage-summary.json.

I might add a configurable precision for the percentages shown in the badges as well.

from jacoco-badge-generator.

Hello, Vincent.

That's cool! Thanks a lot!

I'll try it out now straight away.

Alex.

PS. From my side, I'm absolutely happy with the summary file. It addresses my problem much more efficiently than the configurable precision in the badges.

from jacoco-badge-generator.

Just small semantic note - a new parameter "generate-summary" not only generates the summary but also compares two summaries, to detect the reduced coverage. :)

Some random user of the plugin might get confused by the word "generate" and not expect that all the remaining side-effects will also take place.

from jacoco-badge-generator.

Unless they set either fail-on-coverage-decrease: true or fail-on-branches-decrease: true, the only thing generate-summary: true will do is generate the summary file. The comparison to the previous summary only happens if they use one of those other options in combination. I figured that it is possible someone might just want the calculated percentages for some other reason.

The fail on decrease features will use the new summary report if it exists since that is more accurate, but will also continue to work if the summary feature isn't used as well by just using the less accurate badge percentage.

from jacoco-badge-generator.