Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-25616

Support for coverage.xml generated by Android tools

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • jacoco-plugin
    • None
    • Android Gradle project

      When running gradle createDebugCoverageReport on an Android Gradle project, the built-in JaCoCo support builds an HTML report and an XML report.
      As far as I know it is not possible to use this with Jenkins CI at the moment, because the plug-in wants the .exec file.

      The report XML file starts with the following lines (looks like a standard format?):

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <!DOCTYPE report PUBLIC "-//JACOCO//DTD Report 1.0//EN" "report.dtd">
      <report name="debug">
      <sessioninfo id="unknownhost-a0d58b54" start="1415952183361" dump="1415952207146"/>

      I would love to see support for this in the Jenkins CI JaCoCo plug-in.

      https://github.com/jenkinsci/jacoco-plugin/issues/49

          [JENKINS-25616] Support for coverage.xml generated by Android tools

          Martin Nonnenmacher added a comment - - edited

          +1 from me. It would be great if the plugin would support using existing xml reports.
          I have a script that generates XML and HTML coverage reports and is integrated with the build environment, so it would be much easier to use the reports generated by the script than to keep the configuration of the Jacoco plugin up to date.

          Martin Nonnenmacher added a comment - - edited +1 from me. It would be great if the plugin would support using existing xml reports. I have a script that generates XML and HTML coverage reports and is integrated with the build environment, so it would be much easier to use the reports generated by the script than to keep the configuration of the Jacoco plugin up to date.

          Just for the record, the "createDebugCoverageReport" gets dynamically created by the Gradle Android plugin only if the "debug" build type's "testCoverageEnabled" property is set to "true".

          Sebastian Schuberth added a comment - Just for the record, the "createDebugCoverageReport" gets dynamically created by the Gradle Android plugin only if the "debug" build type's "testCoverageEnabled" property is set to "true".

          Better Shao added a comment - - edited

          I succeeded to get the coverage report on Electric Commander and sonar. The tips is to use "coverage.ec" as the ".exec" file. This is what Google did in Android Gradle Plugin source code.

          public static final String FILE_COVERAGE_EC = "coverage.ec";

          in SimpleTestCallable.java under com.android.builder.internal.testing package.

          Share this so that you will not get stuck here as me.

          Better Shao added a comment - - edited I succeeded to get the coverage report on Electric Commander and sonar. The tips is to use "coverage.ec" as the ".exec" file. This is what Google did in Android Gradle Plugin source code. public static final String FILE_COVERAGE_EC = "coverage.ec"; in SimpleTestCallable.java under com.android.builder.internal.testing package. Share this so that you will not get stuck here as me.

          Mark R added a comment -

          There still is a related issue of having to statically configure the includes/excludes in the plugin configuration. This does not allow for dynamically determining which files to include/exclude.

          Mark R added a comment - There still is a related issue of having to statically configure the includes/excludes in the plugin configuration. This does not allow for dynamically determining which files to include/exclude.

          Arno Moonen added a comment -

          That is not really a solution, betterswc.
          It does not make sense to parse the data again, if the report has already been generated.

          As you can tell, several people on GitHub also have mentioned this to be something they would like to see.

          Arno Moonen added a comment - That is not really a solution, betterswc . It does not make sense to parse the data again, if the report has already been generated. As you can tell, several people on GitHub also have mentioned this to be something they would like to see.

          centic added a comment -

          JENKINS-28652 will provide a way to parse the XML report instead of the binary exec file.

          centic added a comment - JENKINS-28652 will provide a way to parse the XML report instead of the binary exec file.

          Bill Bagdon added a comment -

          still not seeing a way to directly use a generated XML report

          Bill Bagdon added a comment - still not seeing a way to directly use a generated XML report

          centic added a comment -

          JENKINS-28652 was solved in a different way due to lack of dev-time, so unless someone with enough time and skill steps in, this likely won't be available anytime soon, sorry.

          centic added a comment - JENKINS-28652 was solved in a different way due to lack of dev-time, so unless someone with enough time and skill steps in, this likely won't be available anytime soon, sorry.

          Mark R added a comment -

          Any progress with this? The incompatibility between the old and new jacoco exec files will require a transition period where old and new coverage results can be understood. One way to do this would be to consume XML in the Jenkins plugin.

          Mark R added a comment - Any progress with this? The incompatibility between the old and new jacoco exec files will require a transition period where old and new coverage results can be understood. One way to do this would be to consume XML in the Jenkins plugin.

            ognjenb Ognjen Bubalo
            arnom Arno Moonen
            Votes:
            5 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: