feat(checks-rs): make the cargo-tarpaulin install optional - #126
Merged
Conversation
The step installs cargo-tarpaulin whenever enable_coverage is set, which is right for consumers on the default coverage_command (`cargo tarpaulin ...`) and wasted work for anyone who overrides it with another engine. kunobi-frontend moved to cargo-llvm-cov as its primary engine in 2026-07 and supplies llvm-cov through mise, so its coverage run logs "auto-selected engine 'llvm'" and never invokes tarpaulin — but every Rust job still downloads it. On the shared macOS runners that download is also the least reliable step in the job: it has failed three times in a day, alternating between "mv: rename cargo-tarpaulin to $CARGO_HOME/bin/...: No such file or directory" and "sha256sum: *tmp: No such file or directory", killing the job before a single test runs. Add install_tarpaulin, defaulting to true so every existing consumer keeps today's behaviour, and gate the step on it.
jleni
added a commit
that referenced
this pull request
Aug 12, 2026
…#127) #126 added install_tarpaulin defaulting to true, so every consumer that does not use tarpaulin had to know to opt out. That is backwards: across both orgs there are three consumers of this workflow, and none of them installs and uses tarpaulin — the default was protecting a case with no occurrences. Derive it from coverage_command instead, keeping an explicit override: if: enable_coverage && (force_tarpaulin_install || contains(coverage_command, 'tarpaulin')) - Default coverage_command names tarpaulin, so a consumer on the default still gets it installed. A bare `default: false` would have broken them with "cargo tarpaulin: command not found". - Consumers on another engine skip the download with no configuration. - force_tarpaulin_install covers commands that reach tarpaulin indirectly (a make target, a wrapper script), where the string cannot be seen. Renamed from install_tarpaulin to match the narrower meaning. The old name shipped hours ago and has no consumers yet.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Value
install_tarpaulindefaults totrue, so every existing consumer behaves exactly as today. Only a repo that opts out changes.Technical
The step is currently gated on
enable_coveragealone:That is correct for consumers on the default
coverage_command(cargo tarpaulin --all-features --out Json --output-dir .), and pure overhead for anyone who overrides it with a different engine.Concrete case. kunobi-frontend made
cargo-llvm-covits primary engine in 2026-07 and supplies it viamise.toml; itscoverage_commandruns a dual-engine dispatcher that logsrun-rust-coverage: auto-selected engine 'llvm'. Tarpaulin is downloaded on every Rust job and never invoked.Why it matters beyond the wasted minute. The same step is a recurring hard failure on the shared mac runners, in two forms:
Both kill the job during setup. Roughly a coin flip per macOS job recently.
Adds
install_tarpaulin(boolean, defaulttrue) and changes the condition toinputs.enable_coverage && inputs.install_tarpaulin. No other behaviour changes; validated that the workflow YAML still parses and the input is declared as expected.Follow-up: once this lands and
v12is re-pointed, kunobi-frontend setsinstall_tarpaulin: falseon its two_checks-rsjobs. Per the pin policy this is an additive, non-breaking input, so moving the floating major is appropriate — but consumers pinned tov12.0.0are unaffected either way.