pub struct Scope {
pub files: &'static [&'static str],
pub names: &'static [&'static str],
pub opt_in: &'static [&'static str],
pub not_during: &'static [GitState],
}Fields§
§files: &'static [&'static str]Extensions that trigger it. Empty means any change.
names: &'static [&'static str]Exact FILENAMES that trigger it — package.json, Dockerfile —
matched against the path’s basename, never as a suffix: an extension
list cannot say “package.json” without also matching
not-package.json. Builtins keep this empty; the manifest’s scope
column fills it.
opt_in: &'static [&'static str]Config paths that opt a repository in. Empty means always on.
not_during: &'static [GitState]Git operations during which this check does not run.
The other half of “when does this apply”. files and opt_in say which
REPOSITORIES and which CHANGES; this says which repository STATES — a
question that used to be answered by one hard-coded CHERRY_PICK_HEAD
test in one dispatcher, with the other carrying a comment admitting it
had none because the shell version had none.
Implementations§
Source§impl Scope
impl Scope
pub const ALWAYS: Scope
pub const fn files(files: &'static [&'static str]) -> Scope
pub const fn new( files: &'static [&'static str], opt_in: &'static [&'static str], ) -> Scope
Sourcepub const fn not_during(self, states: &'static [GitState]) -> Scope
pub const fn not_during(self, states: &'static [GitState]) -> Scope
The same scope, silent during these operations.
Sourcepub fn is_unscoped(&self) -> bool
pub fn is_unscoped(&self) -> bool
No file gate at all — every change is in scope.
Sourcepub fn touches(&self, paths: &[String]) -> bool
pub fn touches(&self, paths: &[String]) -> bool
Does this gate have work to do, given the files a PUSH changed?
Distinct from matches, and the distinction is the bug this was
written for. matches answers “would this check ever fire in a
repository containing these paths”, so it also consults opt_in —
the marker that says a repository is a Rust one at all. Feeding a
push DIFF to that question conflates two things: whether the
repository is Rust (settled long before, when the dispatcher decided
this check runs here) and whether this push changed any Rust.
pre-push-cargo-test opts in on Cargo.toml. A .rs-only push, in
a repository with a Cargo.toml sitting right there, therefore
answered NO to “is this a Rust repository” — because that one file
was not in the diff — and was judged to have nothing worth attesting.
Which is to say: the most ordinary Rust push there is.
Opt-in is a fact about the repository. This asks only about the change, which is what a caller holding a diff means.
Sourcepub fn covers_all(&self, paths: &[String]) -> bool
pub fn covers_all(&self, paths: &[String]) -> bool
Did the gate see EVERY one of paths? All-match, where matches
is any-match: the caller asking this is deciding whether a commit-time
run COVERED a push, and under-approximating is the safe direction.
Sourcepub fn matches(&self, paths: &[String]) -> bool
pub fn matches(&self, paths: &[String]) -> bool
Would this check ever fire, given the paths a repository contains?
Deliberately coarse for checks that resolve an ancestor at run time —
cargo-fmt declares Cargo.toml meaning “somewhere here” while
enforcing “nearest above the staged file”. The dispatcher asks the
precise question by running the check; this answers the dashboard’s
question, “would it ever fire”, where over-approximating is the safe
direction.