pub struct Scope {
pub files: &'static [&'static str],
pub names: &'static [&'static str],
pub dirs: &'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.
The manifest’s scope column fills this, and so does
pre-commit-hadolint, the first builtin to need it: a Dockerfile has
no extension to gate on.
dirs: &'static [&'static str]Directory-scoped triggers, each written dir/**/*.ext: a path is in
scope when it sits under dir/ and ends with .ext. The manifest’s
scope column is the only writer; a built-in never needs one.
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
Sourcepub const fn named(names: &'static [&'static str]) -> Scope
pub const fn named(names: &'static [&'static str]) -> Scope
Gated on exact basenames rather than extensions — what a Dockerfile
needs, having none.
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.
Sourcepub fn opted_in(&self, paths: &[String]) -> bool
pub fn opted_in(&self, paths: &[String]) -> bool
Does this repository carry the marker that turns the check on?
Split out of matches because the two halves ask about DIFFERENT
path lists, and conflating them is a bug this codebase has now made
twice. touches asks about the CHANGE — the staged set, or the push
diff. This asks about the REPOSITORY, and the only honest source for
that is the index (git ls-files).
Feed a change to this question and it can only answer no unless that
change happened to touch the marker: a +pom.xml row would run when
you edited pom.xml and never when you edited only .java, which is
the ordinary case and the entire point of the gate. See attestable
in dispatch.rs for the first occurrence, in the attestation path.