At a commit and at a push, the project's own tools run after the SpecSheriff tools
At a commit and at a push, the SpecSheriff tools run their checks first, and the project's own tools that run at that moment run after them. The project's own checks run among the checks of the SpecSheriff tools, not after them (§s-2fau85dfyyeq66m). The project's tools run whatever the checks find, and also where the SpecSheriff tools cannot run. The commit or the push goes through only where the checks and each of the project's tools pass. None of the project's tools changes what the commit holds.
A project may run tools of its own at a commit or a push, such as a scan that nothing internal reaches a public repository. The method governs the specification and the code bound to it (§s-efe2cmw9asrbt2g). A tool guarding anything else is the project's own concern, and taking up the method must not stop it. Such a tool makes no check of the method, so the table of checks does not list it. The SpecSheriff tools run first, since the project's tools may extend their checks but never override them. A tool that changed the commit would let through what no check read.
The links it makes
The links made to it
The decisions taken on it
- Problem
Taking up the method set where git looks for hooks, so a project's own tools run at a commit or a push, such as a scan that nothing internal reaches a public repository, had no place to run.
- Ruling
The owner: at a commit and at a push the SpecSheriff tools run their checks first, then the project's own tools, whatever the checks find; both must pass. Operations of git keep their names — commit, push, merge, merge request — and the text names the SpecSheriff tools as such.