Zola 2025-06-27T00:00:00+00:00 https://hanlho.com/tags/rust/atom.xml 2025-06-27T00:00:00+00:00 2025-06-27T00:00:00+00:00 Unknown https://hanlho.com/p/rust-code-coverage-use-llvm-cov-over-tarpaulin/ <p>A few days ago, I wrote about an issue I encountered where the code coverage for one of my projects failed on CI but worked fine locally. <a href="/p/rust-when-cargo-code-coverage-works-locally-but-fails-in-ci/">I also discussed a solution</a>. It turns out there's an even better alternative: switch code coverage tools entirely and use <a href="https://github.com/taiki-e/cargo-llvm-cov">llvm-cov</a> instead of <code>tarpaulin</code>.</p> <p>The main reasons I switched to <code>llvm-cov</code> are that it feels more modern, and more importantly, the time required to run code coverage improved dramatically—from 4 minutes down to just 1 minute and 30 seconds. One contributing factor was an OpenSSL build dependency in my Cargo configuration, introduced by tarpaulin, which took a long time to compile. (To be fair, I probably could have installed OpenSSL as a binary, but I didn't want to introduce another program just for a coverage tool.) Switching to llvm-cov allowed me to remove this redundant dependency, which my project didn't really need in the first place.</p> <p>That's it—just a short update I thought was worth sharing.</p> <p>Thank you for reading,<br /> Hans</p> 2025-06-26T00:00:00+00:00 2025-06-26T00:00:00+00:00 Unknown https://hanlho.com/p/rust-when-cargo-code-coverage-works-locally-but-fails-in-ci/ <p>A short post to help if you run into the same issue.</p> <p><strong>TLDR:</strong> If your code coverage reports show vastly different results between local development and CI, explicitly set <code>--engine llvm</code> in your cargo tarpaulin command.</p> <p>I recently ran into a frustration you may be familiar with: your code works perfectly on your machine, but fails on CI. The most annoying part are the waiting times for CI to finish. You context-switch to other work, if you do not forget, return to debug. It breaks flow and wastes time. Stuff you do not want to be spending time on.</p> <h2 id="the-issue">The issue</h2> <p>My Rust code coverage reports were showing different results between local development (94%) and CI (22%). Same codebase, same test suite.</p> <p>The original cargo command:</p> <pre data-lang="bash" style="background-color:#eff1f5;color:#4f5b66;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">cargo</span><span> tarpaulin</span><span style="color:#bf616a;"> --out</span><span> xml </span></code></pre> <p>Relevant in this case: I test most of my functionality in the <code>tests</code> directory (integration/acceptance tests) and this is the coverage that seemed to be missing.</p> <h2 id="the-solution">The Solution</h2> <p>Add the <code>--engine llvm</code> flag to your cargo tarpaulin command:</p> <pre data-lang="bash" style="background-color:#eff1f5;color:#4f5b66;" class="language-bash "><code class="language-bash" data-lang="bash"><span style="color:#bf616a;">cargo</span><span> tarpaulin</span><span style="color:#bf616a;"> --engine</span><span> llvm</span><span style="color:#bf616a;"> --out</span><span> xml </span></code></pre> <p>This forces <code>tarpaulin</code> to use the coverage engine <em>that works</em> in all environments.</p> <h2 id="explanation">Explanation</h2> <p>Cargo tarpaulin uses different default engines on different platforms. On Linux (CI), it defaults to the <code>ptrace</code> engine. On macOS (my local machine), it uses the <code>llvm</code> engine.</p> <p>The <code>ptrace</code> engine traces system calls to measure coverage. The <code>ptrace</code> engine struggles with tests that spawn subprocesses (like acceptance tests running your compiled binary), whilst the <code>llvm</code> engine handles this correctly.</p>