6

当我使用 codecov.io 记录我的 Rust 项目的代码覆盖率时，覆盖率似乎不正确。

  1. 函数和unwrap()结束括号不包括

    展开和结束支架未覆盖

  2. 函数声明不包括在内

    未涵盖函数声明

这很奇怪。

我无法提供完整的复制项目。

我正在使用 Rust 的标准 TravisCI 配置。这是我的 .travis.yml：

language: rust
cache: cargo
dist: trusty
sudo: required

rust:
  - stable
  - beta
  - nightly

matrix:
  allow_failures:
    - rust: nightly

script:
  - cargo build --verbose --all
  - cargo test --verbose --all

after_success: |
  wget https://github.com/SimonKagstrom/kcov/archive/master.tar.gz &&
  tar xzf master.tar.gz &&
  cd kcov-master &&
  mkdir build &&
  cd build &&
  cmake .. &&
  make &&
  make install DESTDIR=../../kcov-build &&
  cd ../.. &&
  rm -rf kcov-master &&
  for file in target/debug/myproject-*[^\.d]; do mkdir -p "target/cov/$(basename $file)"; ./kcov-build/usr/local/bin/kcov --exclude-pattern=/.cargo,/usr/lib --verify "target/cov/$(basename $file)" "$file"; done &&
  bash <(curl -s https://codecov.io/bash)
  echo "Uploaded code coverage"
4

1 回答 1

0

假设自发布此问题以来 Cargo 和 Travis 的行为没有显着变化，这里有几件事在起作用。

  • 每当构建配置更改时，您的构建指纹就会更改，从而导致完全或部分重建以及生成的二进制文件的新文件名target. 诚然，我不知道发生这种情况的确切时间或原因的复杂性，我只知道它发生了。事实上，对于我正在进行的项目，Cargo 似乎对其中一个依赖项感到非常困惑，以至于它几乎每次都强制重建。
  • Travis 的cache: cargo默认设置非常愚蠢。它缓存所有$CARGO_HOME且target无例外。请注意，这与前者的结合也意味着这些缓存会无限增长，因此您需要偶尔将它们丢弃或使用更智能的缓存方案。
  • for file in target/debug/myproject-*[^\.d]对 的所有构建运行 kcov myproject，无论它是新建的还是来自 Travis 的构建缓存。较旧的构建当然可能具有不同的行号，因为它们是从不同（较旧的）源构建的，并且覆盖范围可能不同。
  • 如果覆盖率结果包含在任何报告中， coverage.io 会通过将其设为红色来合并覆盖率结果，除非它被任何（其他）报告覆盖。如果来自不同报告的行号不匹配，或者即使其中一个报告包含超出 EOF 的行号，它也不会显示任何指示。事实上，据我所知，它甚至没有显示哪些二进制文件覆盖/没有覆盖行号，即使它有这些信息。您必须下载 XML 报告并手动解释它们才能看到。

因此，那些未发现的行可能不是（全部？）是由于 Rust 编译其二进制文件的方式，正如问题的注释所暗示的那样，但实际上可能完全指的是不同的（较旧的）源文件。一段时间后，这在我们的项目中变得非常明显......

覆盖率结果

如果这不是很明显，那么验证这是否正在发生的最简单方法就是丢弃 Travis 的构建缓存并强制重建。

由于增量构建无论如何都不适用于我们的项目，因此我们使用的解决方案是不让 Travis 缓存目标目录，如此处所建议的。根据您的 CI 构建时间取决于增量构建的多少，您可能会被迫做一些更聪明的事情。

于 2019-04-09T08:54:45.380 回答