Closed edwintorok closed 5 years ago
The coverage stuff is certainly a blind spot of topkg
at the moment (@hannesm is also interested).
Initially I just thought you could handle that as an alt
publication target but then this means you need to build the package once more which is a bit wasteful.
I'm fine with using my ./build though, I should probably just add it to my .carcass.
Everything generic that we need to add to each repo is a maintenance curse for scaling package-wise. So this problem has to be solved at some point.
FWIW: I have a custom pkg.ml which handles an --with-coverage
argument over here https://github.com/hannesm/arp/blob/master/pkg/pkg.ml (see commit https://github.com/hannesm/arp/commit/bc57f7001eff1baddac08cbc56815f501c789b42)
While opam has build-test
support, there's no such build-coverage
support - thus there is no explicit dependency on bisect-ppx
anywhere (opam/_tags/META).
I don't have an automated process to publish coverage information (and am not too sure whether it is of interest), but instead a shell script which compiles in coverage mode and renders a html from the output. I personally use coverage analysis when writing test suites, and check coverage after major code changes. For projects with multiple contributors I can see value of automated statistics (e.g. of a PR), and also publishing it alongside with docs.
I'd be delighted to have coverage support using bisect-ppx as a first-class citizen in topkg, similar to the profiling and debugger stuff (see #72). (added later) NB: this does not include any way to publish the results.
I'd be delighted to have coverage support using bisect-ppx
I don't want to commit to a particular coverage framework though.
topkg
is in maintenance mode no new features will be added.
(Last issue for today.)
I have this in my
./build
file:I'd like to use
pkg.ml
hooks instead. It is good thattopkg distrib
builds and tests the distribution in a default configuration, however it could be useful to allow specifying custom flags fortopkg build
, and custom commands to run after testing, then my./build
file could turn into:topkg doc
is run duringtopkg publish
of course, but maybe it wouldn't hurt to run it by default ontopkg distrib
too for testing purposes?I'm fine with using my
./build
though, I should probably just add it to my.carcass
.