zlacker

Why wouldn't I just call the same shell script in CI and locally though? What's the benefit here? All I'm seeing is circular logic.

>>candid+(OP)
The point is enforcement. If there's a newcomer to developing your repo, you can ask them to install the hooks and from thereon everything they commit will be compatible with the processes in your CI. You don't need to manually run the scripts they'll run automatically as part of the commit or push or whatever process

>>candid+(OP)
Yes, you can run the CI script locally so you detect errors faster.

>>candid+(OP)
pre-commit provides a convenient way to organize running a collection of shell scripts.

>>candid+(OP)
If you had a shell script hook, yes you would also run that in CI.

Are you asking what advantage pre-commit has over a shell script?

Mostly just functionality: running multiple hooks, running them in parallel, deciding which hooks to run based on the commit files, "decoding" the commit to a list of files, offering a bunch canned hooks, offering the ability to write and install non-shell hooks in a standard way.

>>candid+(OP)
The pre-commit tool (which prek is based on) has a large ecosystem of off the shelf checks for various language linters and other checks and a convenient way of writing them (including working out which files have changed and which checks to run based off of that)

The benefit to many of having them as a hook is that you discover it's broken before you pushed your changes, and not when you finally get around to checking the CI on your branch and realising it failed after 30s.

There is of course no reason why you have to have it installed as a precommit hook - many people prefer to run it manually, and the pre-commit tool/prek allows for that.