fix(checks-rs): detect the tarpaulin install instead of asking for it - #127
Merged
Conversation
#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
coverage_commandkeep working unchanged.Technical
The data. Searching both orgs for consumers of
_checks-rs.yamlreturns three workflow files:kunobi-frontend/ci.yaml(two jobs,enable_coverage: truebutcoverage_commandoverridden to a cargo-llvm-cov dispatcher),kunobi-frontend/benchmark.yaml(enable_coverage: false), andweb-golem/ci.yaml(@v11,enable_coverage: false). None installs and uses tarpaulin.default: truewas protecting a case with no occurrences.Why not simply
default: false. The workflow's own defaultcoverage_commandiscargo tarpaulin --all-features --out Json --output-dir ., so a future consumer taking the default would have hitcargo tarpaulin: command not found— a silent break traded for the current one.The change derives the decision from the command and keeps an explicit override:
coverage_command(names tarpaulin)make coverage) +force_tarpaulin_install: trueWhy keep an input at all rather than rely on the string alone: a command like
pnpm run coverageormake coveragecan invoke tarpaulin without naming it, and the heuristic cannot see that.force_tarpaulin_installis the escape hatch, named for what it now does.Renamed from
install_tarpaulin; it shipped hours ago in feat(checks-rs): make the cargo-tarpaulin install optional #126 and has no consumers yet, so no migration is needed.Verified the workflow parses and that the condition evaluates correctly for all three cases above.
Follow-up to #126.