Cargo tarpaulin: 0.22.0 Rust: 1.65.0 OS: ubuntu0.20.04.1
Describe the bug For some reason the command fails on my build runner while it works on my local Mac OS machine. The test relies on a certain environment config and I ensured that the file is in place. As it seems it does not start executing any tests.
Run RUN_MODE=emea-test-local cargo tarpaulin --release --out Lcov --timeout 600
Dec 07 15:41:08.003 INFO cargo_tarpaulin::config: Creating config
Dec 07 15:41:08.626 INFO cargo_tarpaulin: Running Tarpaulin
Dec 07 15:41:08.626 INFO cargo_tarpaulin: Building project
Dec 07 15:41:08.626 INFO cargo_tarpaulin::cargo: Cleaning project
Compiling autocfg v1.1.0
...
Finished release [optimized] target(s) in 1m 56s
Dec 07 15:43:05.753ERROR cargo_tarpaulin: Error while parsing
Error: "Error while parsing"
To Reproduce These are my dependencies.
[dependencies]
axum = "0.6.1"
axum-extra = { version = "0.4.0", features = ["spa"] }
axum-sessions = "0.4.0"
chrono = { version = "0.4.21", features = ["serde"] }
config = { version = "0.13.1", features = ["yaml"], default-features = false }
dashmap = "5.3.4"
eyre = "0.6.8"
futures = "0.3.23"
futures-util = "0.3.23"
http-auth-basic = "0.3.3"
hyper = { version = "0.14.20", features = ["full"] }
hyper-tls = "0.5.0"
ldap3 = { version = "0.10.5", default-features = false, features = ["tls"] }
openidconnect = "2.3.2"
rand = { version= "0.8.5", features = ["min_const_gen"] }
regex = "1.6.0"
serde = { version = "1.0.138", features = ["derive"] }
serde_json = "1.0.83"
sqlx = { version = "0.6.0", features = [ "runtime-async-std-native-tls", "postgres", "macros", "chrono", "json" ], default-features = false }
strum = "0.24"
strum_macros = "0.24"
tokio = { version = "1.0", features = ["full"] }
tokio-tls = "0.3.1"
tower = "0.4.13"
tower-http = { version = "0.3.0", features = ["fs", "trace", "add-extension", "auth"], default-features = false }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter"] }
url = "2.3.1"
Expected behavior Successfull run.
Our team is experiencing the same issue with our CI runs using tarpaulin. You can see the CI run here. It is using the xd009642/tarpaulin:develop-nightly
image.
Error message:
Jan 11 13:38:22.972 ERROR cargo_tarpaulin: Error while parsing
Jan 11 13:38:22.969 INFO cargo_tarpaulin::process_handling::linux: Launching test
Jan 11 13:38:22.977 INFO cargo_tarpaulin::process_handling: running /home/runner/work/relayer/relayer/target/debug/deps/webb_block_poller-ebb29a8c88f0e56b
Error: "Error while parsing"
Is there any update or way to resolve this @xd009642? We have been facing similar issue on some of our repos
I'll look at it this weekend, it's not every project (most work fine) so still trying to track what makes these projects or builds different
@dutterbutter looking at your CI job initially I would recommend using a newer tarpaulin - and avoiding actions-rs/tarpaulin
it seems to be broken in some way (my latest github releases with apple and windows prebuilt assets likely won't work at all). Personally, cargo-binstall
is my preferred approach for avoiding slower installs in CI.
EDIT:
I see what it is for relayer, strip = "symbols"
without any symbols tarpaulin's ptrace coverage (default on linux) has no debug info and can't get coverage data as it's a breakpoint based coverage system (I'll improve error messaging here). You can keep strip in potentially if you use --engine llvm
(I need to test this). However, llvm coverage instrumentation seems to not work in docker so you would need to use a different way of running tarpaulin in CI (though your linked job doesn't use docker)
@lcmgh @dutterbutter can I take from the heart reacts on latest message that solved the issue? If so let me know and I'll close the issue (or lcmgh can close it :smile: ). I've done the updates to log to improve messages if no debug info is in the files and that plus proving llvm coverage works with strip means afaik this is done :eyes:
@xd009642 yes thanks for all the work and responses here! Greatly appreciated!!!
@xd009642 stripping the binary was indeed the root cause of the failure in my case! Thanks too!