Closed azriel91 closed 1 year ago
Is it the coverage data that is actually increasing disk space usage? Or is it the build artifacts? (From my experience, I think it is most likely due to the latter. e.g., https://github.com/taiki-e/cargo-hack/issues/47. And in the latter case, the merging of coverage data you suggest is not very helpful.)
It does look like the coverage data, this is the cumulative disk space usage within the target
directory as coverage is run for different feature sets:
no-features:
5.2G ├── llvm-cov-target
17G ├── debug
--features "one_feature":
11G ├── llvm-cov-target
17G ├── debug
--all-features:
18G ├── llvm-cov-target
17G ├── debug
The debug
directory stays at 17G, and the number of target/llvm-cov-target/*.profraw
s increases.
It is a relatively large project, and I think perhaps using llvm-cov
to help me remember "i haven't tested this code!" with that many feature sets doesn't work so well.
I've decided to reduce the number of features and "always include the code" -- makes it easier for maintenance overall with fewer custom code paths :slightly_smiling_face:.
But thanks for bringing up cargo-hack
, I haven't tried it out
The default target directory for cargo-llvm-cov is target/llvm-cov-target
not target
. So it is not clear from the information you have provided which is the increase.
ah, the above disk usages are the directories within target
, as in target/llvm-cov-target
was growing from 5.2 G to 18G as more commands were run:
cargo llvm-cov --no-report nextest --workspace --no-default-features
cargo llvm-cov --no-report nextest --workspace --features output_progress
cargo llvm-cov --no-report nextest --workspace --all-features
but target/debug
was constant at 17G -- though that would've been from all the builds during ongoing development. When I first opened the issue, I had 5 different sets of cargo llvm-cov .. --features "f1 f2 f3"
combinations, which brought target/llvm-cov-target
up to 30G.
(This appears to have been closed without being resolved, but https://github.com/taiki-e/cargo-llvm-cov/issues/335 was opened with some new information about the disk space issue, so I'll leave it closed in favor of that.)
Heya :wave:,
In one of my projects, I run coverage with different combinations of features, which generates about 30 GB of coverage data. GitHub Actions runners have less than that amount of disk space.
Is there a way to merge coverage into a report incrementally, and remove previous coverage files before running the next combination?