Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching to using the JaCoCo JVM Agent #720

Open
shanshin opened this issue Dec 20, 2024 · 0 comments
Open

Switching to using the JaCoCo JVM Agent #720

shanshin opened this issue Dec 20, 2024 · 0 comments
Assignees

Comments

@shanshin
Copy link
Collaborator

We have decided to transition to using the JaCoCo agent for Kotlin Coverage.

As part of this change, the current IntelliJ agent, used in the existing Kover Gradle and Maven plugins as well as the CLI, will be deprecated.
This will be carried out as part of the transformation of Kover from a separate plugin into a part of Kotlin.

Motivation

Over time, IntelliJ agent differs less and less from JaCoCo and after supporting inline functions, the JaCoCo agent will be equivalent to the IntelliJ agent in its set of capabilities.
It doesn't make sense to support two different agents with different infrastructure and incompatible execution file formats.
Using another agent forces to use incompatible tools (like reporter and plugins), change build scripts and plugins and pipelines on CI.

Instead of providing alternatives with mandatory migration to products with a different workflow, we decided to integrate as much as possible with an existing and proven product, while adding additional features that will improve the experience with Kotlin.

Changes in approach

  • The JaCoCo agent will replace the IntelliJ agent
  • XML reports will generating using the JaCoCo distribution
  • JaCoCo HTML report will be generating via the JaCoCo distributive
  • a Kotlin-specific HTML report generator will be built on top of the JaCoCo reporter
  • a Kotlin Coverage report for exporting data will be built on top of the JaCoCo reporter
  • these reporters will also consume execution files generated by the JaCoCo agent
  • these reporters will be distributed separately in the form of CLI and kotlin JVM dependency
  • if necessary, we will create a fork of JaCoCo to implement bug fixes or add features specific to Kotlin. To prevent agents from starting to disperse, we are simultaneously creating a PR in JaCoCo so that these changes become available to the entire community

Action points

  • analyze open bugs on Intelij JVM Agent, check them on the current JaCoCo master build. If the problem does not reproduce in JaCoCo, then mark it as a task to close, if reproduced then create the corresponding bug in JaCoCo.
  • compare ways to configure agents (for example, filters) so that when switching to JaCoCo, the same configuration gives the same report
  • compare the coverage details between agents, if the behaviour of JaCoCo is very different for some language constructs and this is not technically justified, then we should start a design task as a potential change for the next version of JaCoCo.
  • deprecate the use of Kover Coverage Tool in Kover Gradle Plugin and change Coverage Tool in Kover Maven Plugin
  • design Kover-specific HTML report and Kover Coverage report
  • implement reporter for Kover-specific HTML report and Kover Coverage report on top of the JaCoCo reporter
  • implement Kover CLI with Kover reporter, JaCoCo reporter and JaCoCo offline instrumenter inside
  • add integration with Android Gradle Plugin to get execution report after running Android instrumentation tests to include them in the report; add synchronization of the JaCoCo version between AGP

Migration to Kotlin Gradle Plugin

The transition to JaCoCo will be carried out in parallel with the migration of logic to KGP.

It should be completed before the migration of Kover Gradle Plugin to Kotlin Gradle Plugin, however, some work may continue after the migration (for example, creating Kotlin-specific reports)

@shanshin shanshin added Feature Feature request issue type S: untriaged Status: issue reported but unprocessed labels Dec 20, 2024
@shanshin shanshin self-assigned this Dec 20, 2024
@shanshin shanshin removed S: untriaged Status: issue reported but unprocessed Feature Feature request issue type labels Dec 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant