The project's own tools in a git hook
Each git hook sheriff init writes runs the project's own tools for it after the checks of the SpecSheriff tools (§s-pcnyfp7gev7syax). They are the files directly in .githooks/<hook>.d/ whose first line names their interpreter, run in the byte order of their names. A first line names an interpreter where it opens with #!, followed by a path and at most one argument, a closing carriage return left out. The hook names each other file there and does not run it.
The hook runs them whatever the checks found, the script refusing where Node is missing or too old included, and also where it finds no SpecSheriff tools (§s-4mej6ccn7xu3d3p). Each of the project's tools:
- runs from the root of the working tree, by the interpreter its first line names, in git's own environment, so it reads the working tree and git's index;
- is handed the arguments git hands the hook and a copy of the standard input git hands it.
Each of them runs, whatever the others find. The hook fails where the checks refuse or one of the project's tools ends with an exit status other than zero, naming each such tool. It fails too where one of them changes the staged files or the commit's message, naming it.
These files are among the repository's own tools, not the system's code (§s-hheus6f395ynqvc).
A repository taking up the method has its hooks in .githooks/, which core.hooksPath names, so git runs the project's own tools nowhere else. Kept in a folder of their own, they are the project's files, which sheriff init neither replaces nor names as changed by hand. Each of them runs, so that each reports what it would report alone. One is chosen by its first line rather than by the executable bit, which a file committed from a system keeping none loses. The pre-push hook's input names the refs pushed, which a tool judging a push needs as the hook does.
The links it makes
The links made to it
The decisions taken on it
- Problem
The project's own tools needed a way to be registered that a hook can read even where no SpecSheriff tools are on the machine.
- Ruling
The owner: a project registers its own tools for a hook by placing them in .githooks/
.d/, which the hook reads at every run, rather than by a list in sheriff.config.json, which a hook without the SpecSheriff tools could not read; sheriff init neither knows nor registers them.
The tests bound to it
- skills/tools/test/e2e/hooks.test.ts · s-n4m5zvh96yb299p runs the project's own tools in git's own environment, the locale they are listed in held to the listing
- skills/tools/test/e2e/hooks.test.ts · s-n4m5zvh96yb299p runs the project's own tools of a hook after the checks, names a file it does not run, and fails where one fails or changes the staged files