ci: adopt the fleet reusable workflow - #6
Merged
Merged
Conversation
Replaces the hand-maintained per-repo workflow with the shared one. No inputs:
this repo already enforced a 100% per-line coverage gate at
`--workspace --all-features`, which is the shared workflow's default, and MSRV
is read from rust-version. Configuring anything here would be a behaviour change
smuggled in by an adoption PR.
Every job the old workflow ran is covered — fmt, clippy, test, MSRV, cargo-deny,
cargo-vet and the secret scan. Adoption also ADDS checks this repo did not have:
a path-dependency gate, a fuzz build-check, and rustdoc with warnings denied.
Two fleet-wide defects are retired as a side effect, neither of them fixed here
by hand:
`cargo fetch` before `--locked` The shared workflow runs `cargo fetch
--locked`. A bare `cargo fetch` RE-RESOLVES
and rewrites Cargo.lock, so the `--locked`
check that follows validates a lockfile the
runner just generated — a gate structurally
unable to fail. Measured in 62 fleet repos
and demonstrated directly: with the committed
lock `--locked` fails, and after `cargo
fetch` it passes.
gitleaks from `releases/latest` Resolved at job time from an unauthenticated
GitHub API call, which is rate-limited on
shared runners: the version comes back empty
and the download 404s. ~1 run in 40 across 25
repos. The shared workflow pins the version.
The workflow reference is pinned to a full commit SHA, per the fleet
supply-chain rule that CI dependencies are never floating tags.
…e gate
Correcting the adoption commit in this PR. It claimed no inputs were needed
because the repo "already enforced a 100% per-line gate". That was wrong here:
the workflow being replaced gated on
cargo llvm-cov ... --fail-under-functions 100
which is 100% of FUNCTIONS, with no line gate at all. Inheriting the shared
workflow's default therefore imposes a gate this repo has never run under —
100% of every executable LINE.
Measured at the fleet scope (--workspace --all-features): 95.84% of lines. The
strict gate would have failed on that difference alone, for a rule nobody chose
in this PR.
The floor is set to 95, just under the measured value, so it holds the line
rather than granting slack — a real regression still fails — and the shared
workflow renders it in the checks UI as migration debt with a warning on every
run, not as a passing gate.
The 100% function gate is dropped either way: the shared workflow has no
function-coverage input. That is a genuine reduction and is stated here rather
than left to be discovered. Restoring it, or raising this floor toward 100%
lines, is separate work that has to argue for itself — an adoption PR is the
wrong place to change what CI accepts.
REMOVE WHEN: the uncovered lines are tested or the provably-dead arms carry
`// cov:unreachable: <invariant>`, and this repo can inherit
`coverage-gate: strict`.
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.
Replaces the hand-maintained per-repo workflow with the shared one. No inputs:
this repo already enforced a 100% per-line coverage gate at
--workspace --all-features, which is the shared workflow's default, and MSRVis read from rust-version. Configuring anything here would be a behaviour change
smuggled in by an adoption PR.
Every job the old workflow ran is covered — fmt, clippy, test, MSRV, cargo-deny,
cargo-vet and the secret scan. Adoption also ADDS checks this repo did not have:
a path-dependency gate, a fuzz build-check, and rustdoc with warnings denied.
Two fleet-wide defects are retired as a side effect, neither of them fixed here
by hand:
cargo fetchbefore--lockedThe shared workflow runscargo fetch --locked. A barecargo fetchRE-RESOLVESand rewrites Cargo.lock, so the
--lockedcheck that follows validates a lockfile the
runner just generated — a gate structurally
unable to fail. Measured in 62 fleet repos
and demonstrated directly: with the committed
lock
--lockedfails, and aftercargo fetchit passes.gitleaks from
releases/latestResolved at job time from an unauthenticatedGitHub API call, which is rate-limited on
shared runners: the version comes back empty
and the download 404s. ~1 run in 40 across 25
repos. The shared workflow pins the version.
The workflow reference is pinned to a full commit SHA, per the fleet
supply-chain rule that CI dependencies are never floating tags.