chore(ci): delete the unsafe audit that cannot fail - #7
Merged
Conversation
- run: cargo geiger 2>&1 || true
continue-on-error: true
`|| true` on the step and `continue-on-error` on the job: this check has never
been capable of reporting anything. It is also a SIBLING of the shared-workflow
call rather than a job inside it, so `ci / All checks` never reached it and
branch protection never required it. Eighteen repos carried a byte-identical
copy.
Deleting rather than fixing, because a working exit code would not help. Where
`unsafe_code = "forbid"` is in force, `unsafe` is a compile error, so a job
asserting its absence still could not fail -- the same defect with a healthier
appearance.
The real control is now in the shared workflow: `Unsafe lint audit` asserts
that every workspace member EFFECTIVELY forbids or denies `unsafe_code`, which
is the part the compiler cannot tell you. A member with no `[lints]` table does
not inherit workspace lints (inheritance is opt-in via `[lints] workspace =
true`), and a member with its own `[lints]` table replaces inheritance rather
than extending it. Either way it compiles with `unsafe` permitted while the
workspace root still reads compliant. That check lives inside the gate, is
required by branch protection, and found five unprotected published crates on
its first run.
A check that cannot fail is worse than no check: it reads as coverage that does
not exist.
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.
|| trueon the step andcontinue-on-erroron the job. This check has never been capable of reporting anything. It is also a sibling of the shared-workflow call rather than a job inside it, soci / All checksnever reached it and branch protection never required it. Eighteen repos carried a byte-identical copy;safe-reada nineteenth.Deleting rather than fixing
A working exit code would not help. Where
unsafe_code = "forbid"is in force,unsafeis a compile error — a job asserting its absence still could not fail. That is the same defect with a healthier appearance.The real control now exists
Unsafe lint auditin the shared workflow asserts that every workspace member effectively forbids or deniesunsafe_code— the part the compiler cannot tell you:[lints]table does not inherit workspace lints; inheritance is opt-in via[lints] workspace = true[lints]table replaces inheritance rather than extending itEither way it compiles with
unsafepermitted while the workspace root still reads compliant. That job lives inside the gate, is required by branch protection, and found five unprotected published crates on its first run across the fleet.A check that cannot fail is worse than no check: it reads as coverage that does not exist.