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.

0

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"
1

Is there any update or way to resolve this @xd009642? We have been facing similar issue on some of our repos

0

Which is the latest version not affected by this issue?

0

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

1

@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)

2

@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:

1

@xd009642 yes thanks for all the work and responses here! Greatly appreciated!!!

0

@xd009642 stripping the binary was indeed the root cause of the failure in my case! Thanks too!

0
© 2022 pullanswer.com - All rights reserved.