gradle-print-coverage-plugin icon indicating copy to clipboard operation
gradle-print-coverage-plugin copied to clipboard

Task should not fail if xml report is not enabled

Open fabianMendez opened this issue 6 years ago • 3 comments

Since this plugin relies in the xml report being enabled for the jacoco plugin:

jacocoTestReport {
    reports {
        xml.enabled true
    }
}

https://github.com/jansauer/gradle-print-coverage-plugin/blob/a121d160a1bcfb1f97918a9da77e79df337ffb72/src/main/groovy/de/jansauer/printcoverage/PrintCoverageTask.groovy#L25-L29

It should not fail if this report is not enabled and maybe it could show a warning

Also, it could be better if the path of the report is taken from jacocoTestReport.reports.xml.destination

fabianMendez avatar Jan 28 '19 13:01 fabianMendez

Hi @fabianMendez My train of thought was that if the plugin already enables the jacoco report and it is still not there something is going really wrong and only writing an error and a still successful build would not be enough. Do you have a use case were this would be desirable?

I thing that i had tried the part with the destination configuration but it didn't worked. Since I can't remember what the reason was i will give it a second go :-D having a hardcoded path is really bad taste.

jansauer avatar Feb 03 '19 19:02 jansauer

My problem was that the xml report is not enabled by default and the README does not mention that it should be enabled, so I had to search the error message in this repository which lead me to the conclusion that I had to enable it.

Updating the readme should be enough :+1:

fabianMendez avatar Feb 03 '19 20:02 fabianMendez

I had an issue with composite builds, as the plugin was confused about where project.buildDir is. I think the error was good for failing the build, but not too helpful.

Another way of thinking would be to generate a warning and set the task output to SKIPPED or NO-SOURCE, which could be achieved easily with newer Gradle APIs. I think the is what I would expect, but maybe this is just me. :wink: (Or make it configurable.) In my case the GitLab CI would have failed, because no coverage output was found.

I am happy to contribute to a solution!

manuelprinz avatar Aug 13 '22 11:08 manuelprinz