Skip to content
This repository has been archived by the owner on Aug 24, 2019. It is now read-only.

Add ability to convert from one coverage format to another #38

Open
samcday opened this issue Nov 5, 2015 · 7 comments
Open

Add ability to convert from one coverage format to another #38

samcday opened this issue Nov 5, 2015 · 7 comments

Comments

@samcday
Copy link

samcday commented Nov 5, 2015

It would be awesome if I could convert from any of the formats support for parsing to another format. i.e JaCoCo -> LCOV, Go Cover -> Clover, etc.

@foresmac
Copy link
Contributor

foresmac commented Nov 5, 2015

All the parsing is handled via modules; for instance, see:
https://github.com/vokal/cobertura-parse

CVR itself merely needs coverage data to be in a consistent format for processing (and eventual display). I don't see a use case for CVR, but you may find it useful to look at the above parsers to help you achieve what you are looking for.

@foresmac foresmac closed this as completed Nov 5, 2015
@jrit
Copy link
Contributor

jrit commented Nov 5, 2015

I would like to see modules that would take the common coverage objects and would write them to formats like LCOV or Go Cover, but those modules would need to be made. CVR could then manage the pipelines from one format to another. That pipeline would always be coverage format > common coverage object > other coverage format

@foresmac
Copy link
Contributor

foresmac commented Nov 5, 2015

I see no reason we couldn't add an "unparse" function to each respective module, but I'm really curious what the use case would be for such a pipeline in CVR?

@jrit
Copy link
Contributor

jrit commented Nov 5, 2015

The heading on the main readme is "Tools for working with code coverage reports." so I think that qualifies as a good use case in meeting that stated purpose.

@foresmac foresmac changed the title Format back to LCOV / JaCoCo / Cobertura / Go Cover? Add ability to convert from one coverage format to another Nov 5, 2015
@foresmac foresmac reopened this Nov 5, 2015
@foresmac
Copy link
Contributor

foresmac commented Nov 5, 2015

The first step then is to either support reversing from a JSON object into a particular coverage format, either in existing modules or new ones designed for this purpose. Once we have that, then we can figure out a way to manage the pipeline.

@samcday
Copy link
Author

samcday commented Nov 6, 2015

Let me add some more context on why this could be useful for various people. There's various scripts floating around that handle converting from one coverage format to another. However, these scripts are at varying levels of maturity, and aren't consolidated nicely into one tool like CVR.

i.e:

In my case, I have a project that uses JaCoCo for code coverage, but I run the build on Bamboo and happen to need the coverage report in Clover format. I wish I was joking, but the only way I could figure out how to do that was to convert JaCoCo into Cobertura, and then Cobertura into Clover.

@jrit
Copy link
Contributor

jrit commented Nov 6, 2015

@samcday totally agree.

As long as all the parsing modules can create and consume the same format, what is called Common Coverage Object on the readme here https://github.com/vokal/cvr then everything should be able to interoperate. If you are interested in making some additions to or writing some new parsing modules and need any questions answered, just let me know.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants