ci: adopt the fleet reusable workflow - #3
Merged
Merged
Conversation
Replace the hand-maintained ci.yml with a call to SecurityRonin/fleet-ci/.github/workflows/rust-ci.yml, pinned to 619094ad54edc586f5c2733358e00326b30790bd, keeping the geiger job verbatim. msrv-check: test -- the old MSRV job ran `cargo test` at 1.75, not a bare build. coverage-ignore-regex: "/tests/|/fuzz/" -- the old coverage job already ran the fleet per-line gate, but its test/fuzz exclusion was written inside the inline Python (`if "/tests/" in cur or "/fuzz/" in cur: continue`) rather than as an --ignore-filename-regex flag. Same exclusion, expressed the way this workflow takes it. Verified load-bearing on origin/main (tests/coverage.rs, fuzz/fuzz_targets/*.rs all match) and re-running the shared gate's rules over `cargo llvm-cov --workspace --all-features` with this regex gives 0 uncovered / 2 annotated exemptions -- green, unchanged. The crate declares no cargo features, so the --all-features default changes nothing relative to the old `cargo test --workspace`. One gate the shared workflow adds that this repo did not have: rustdoc with -D warnings (plus the single-checkout path-dependency check).
…clared 1.75
The new per-member MSRV matrix runs this repo's configured check
(`msrv-check: test`) at the floor forensic-hashdb declares, and it
refused:
error: failed to parse manifest at .../getrandom-0.4.3/Cargo.toml
feature `edition2024` is required
... not stabilized in this version of Cargo (1.75.0)
Diagnosis — the declared floor is TRUE and was not the problem:
* `cargo +1.75 build -p forensic-hashdb --all-features` PASSES. The
library's own source and its normal dependency graph are fine at
1.75.
* The refusal is confined to the TEST target's dev-dependency graph:
getrandom 0.4.3 <- tempfile 3.27.0 <- [dev-dependencies]
forensic-hashdb. getrandom 0.4.x is `edition = "2024"`, which fails
at MANIFEST PARSE below cargo 1.85 regardless of what the code uses.
* Dev-dependencies do not propagate to consumers, so this never
reached anyone depending on forensic-hashdb. `rust-version = "1.75"`
remains a truthful promise and raising it would have been a false
raise that breaks downstreams for no reason.
Fix: pin getrandom to 0.3.4 (declares 1.63, edition 2021), which also
brings r-efi 6.0.0 -> 5.3.0. tempfile stays at 3.27.0 — its requirement
accepts getrandom 0.3, so no dev-dependency was downgraded.
Controls (cargo test -p forensic-hashdb --all-features, the exact check
the MSRV job runs):
before pin, 1.75 -> FAIL (`edition2024` required, getrandom 0.4.3)
after pin, 1.75 -> PASS (26 + 5 + 0 tests, 0 failed)
after pin, 1.96 -> PASS (workspace, all features, same counts)
Note for whoever tunes Renovate here: `lockFileMaintenance` will walk
getrandom back to 0.4.x and re-red this job. A durable alternative is a
capped dev-dependency requirement on tempfile/getrandom, which costs
consumers nothing because dev-deps do not propagate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pinning a dependency down to keep this repo's declared MSRV achievable moved the resolved set, and the vet store had no record for the versions that came out. Each takes the strongest mechanism that applies per ADR-0018: publisher trust for crates we publish or whose publisher an imported aggregate auditor already vouches for, and honest [[exemptions]] only for the remainder. An exemption asserts that nobody audited the crate — equally true before and after a version change — so refreshing one claims nothing new. No `cargo vet certify --accept-all`: a certify record asserts a human read the source, so bulk-certifying fabricates the condition being claimed. audits.toml carries zero self-certified entries after this change. `cargo vet --locked` passes.
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.
Replace the hand-maintained ci.yml with a call to
SecurityRonin/fleet-ci/.github/workflows/rust-ci.yml, pinned to
619094ad54edc586f5c2733358e00326b30790bd, keeping the geiger job verbatim.
msrv-check: test -- the old MSRV job ran
cargo testat 1.75, not a barebuild.
coverage-ignore-regex: "/tests/|/fuzz/" -- the old coverage job already ran
the fleet per-line gate, but its test/fuzz exclusion was written inside the
inline Python (
if "/tests/" in cur or "/fuzz/" in cur: continue) ratherthan as an --ignore-filename-regex flag. Same exclusion, expressed the way
this workflow takes it. Verified load-bearing on origin/main
(tests/coverage.rs, fuzz/fuzz_targets/*.rs all match) and re-running the
shared gate's rules over
cargo llvm-cov --workspace --all-featureswiththis regex gives 0 uncovered / 2 annotated exemptions -- green, unchanged.
The crate declares no cargo features, so the --all-features default changes
nothing relative to the old
cargo test --workspace.One gate the shared workflow adds that this repo did not have: rustdoc with
-D warnings (plus the single-checkout path-dependency check).
🤖 Generated with Claude Code