Repository navigation
ci: adopt the fleet reusable workflow - #4
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.
Adopting the shared workflow added a secret scan this repo never ran, and it
reported `leaks found: 1`. Investigated rather than assumed noise, because a
scan that fires on real credentials and a scan that fires on hex constants look
identical from the check name.
It is a false positive, and specifically:
rule generic-api-key
file crates/pe-core/src/rich_header.rs:143
commit 0d275c3 (2026-05-30), found by scanning git history, not the tree
value let key = 0x1234_5678_u32;
PE Rich headers are XOR-obfuscated with a per-binary key, so a parser's tests
have to construct one, and 0x12345678 is the canonical placeholder. It is the
INPUT the test decodes, not a credential. gitleaks scores it on entropy alone
(3.51) and cannot distinguish a domain constant from a token.
No rotation is warranted: nothing here was ever a secret. That determination is
the point of investigating rather than allowlisting on sight — had this been a
real credential reachable in history, deleting the line would not have been
enough, since GitHub keeps old commits fetchable by SHA.
The allowlist is scoped to that exact literal, NOT to the file and NOT to the
rule. Suppressing `generic-api-key` repo-wide would disable the gate for
everything to excuse one hex constant, and a future real secret in the same file
would still surface under this scoping. 61 fleet repos already ship a
.gitleaks.toml on the same pattern — each narrowed to its own known finding —
and this repo was simply missing one.
Verified by control: with the allowlist gitleaks reports 0 findings; with it
removed, the finding returns. The check can still fail.
Adopting the shared workflow added a rustdoc gate this repo never ran, and it
fails:
error: unresolved link to `14`
--> crates/exec-pe-core/src/parser.rs:31:53
The doc comment describes the CLR runtime header as `directory[14]`. Markdown
reads `[14]` as a reference-style link, so rustdoc looks for an item named `14`,
finds none, and `-D warnings` turns that into an error.
Backticking makes it a code span, which is what it always was — an index into
the PE data-directory array, not a cross-reference. No prose meaning changes.
Verified by control rather than by reading the green: with the backticks
`cargo doc --no-deps --workspace --all-features` passes under
RUSTDOCFLAGS="-D warnings"; reverting them fails again on the same line.
Worth noting the shape, because it will recur across the fleet as more repos
adopt the rustdoc gate: any bare `[n]` in a doc comment — array indices, RFC
references, footnote markers — is a link as far as rustdoc is concerned.
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.