Library for processing code coverage reports.
Supported formats include:
codecov-rs's SQLite format described in src/report/models.rsSee core/src/parsers or the list of features in core/Cargo.toml for a complete list. All formats are converted to codecov-rs's SQLite format (inspired by coverage.py) and converting back is generally not a goal (pyreport being the exception).
All details (e.g. SQLite schema, code interfaces) subject to breaking changes until further notice. In the future, we will at least use SQLite's schema_version pragma to attempt backwards compatibility.
Set up your development environment:
codecov-rs requires the nightly compiler for niceties such as #[feature(trait_alias)].source .envrc (or use direnv) to set up a virtual environment. Update development dependencies with pip install -r python/requirements.dev.txtpip install pre-commit && pre-commit install.test_utils/fixtures/**/large directories (e.g. test_utils/fixtures/pyreport/large). Tests and benchmarks may reference them so installing it yourself is recommended.codecov-rs aims to serve as effective documentation for every flavor of every format it supports. To that end, the following are greatly appreciated in submissions:
/// / /**). For parsers, include snippets that show what inputs look likeThe core/examples/ directory contains runnable commands for developers including:
parse_pyreport: converts a given pyreport into a SQLite reportsql_to_pyreport: converts a given SQLite report into a pyreport (report JSON + chunks file)You can run an example with cargo run --example <example> <arguments>. Consider following suit for your own new feature.
core/: Rust crate with all of the core coverage-processing functionalitybindings/: Rust crate with PyO3 bindings for core/test_utils/: Rust crate with utilities for Rust tests and sample data for any tests
test_utils/fixtures: Checked-in sampled data. Large samples are checked in with Git LFSpython/codecov_rs: Python code using/typing the Rust crate in bindings/python/tests: Python testsCargo.toml in the root defines a Cargo workspace. pyproject.toml in the root defines our Python package. Development dependencies for the Python code are in python/requirements.dev.txt.
TBD: Design not settled
New parsers should be optional via Cargo features. Adding them to the default featureset is fine.
Where possible, parsers should not load their entire input or output into RAM. On the input side, you can avoid that with a streaming parser or by using memmap2 to map the input file into virtual memory. SQLite makes it straightforward enough to stream outputs to the database.
Coverage formats really run the gamut so there's no one-size-fits-all framework we can use. Some options:
quick_xml, a streaming XML parserwinnow, a parser combinator framework (fork of nom)
winnow's docs illustrate how one can write a streaming parserserde, a popular serialization/deserialization framework
serde's docs illustrate how one can write a streaming parserNon-XML formats lack clean OOTB support for streaming so codecov-rs currently relies more on the mmap approach.
Run tests with:
# Rust tests
$ cargo test
# Python tests
$ pytest
Run benchmarks with:
$ cargo bench --features testing
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4