One of the benefits of CI is that I don't need to make assumptions about the environment I'm operating in - that is, I don't need to worry about a tool like `jq` being installed, whether I have GNU or BSD `date`, or the biggest one in this case, whether I've even installed a commit hook after cloning the repo. It only takes one new hire that hasn't set up the hooks to merge a change that makes the repo fail checks.
A post-receive hook runs on your git server, in an environment just as known to you.
It denies all pushes which doesn't meet the specified requirements with an error message, and the end user has to re-do the commit and push again.
This is likely how your authorization is done today already.
The alternative would be a pre-commit hook, but that runs when crafting the commit, and under the control of the end user. That can make for a better user experience since it runs even earlier in the process but isn't necessarily secure. Of course, one can have both.
Agreed. The usual way I do this is I set up a pre-commit (pre-commit.com) configuration that runs locally, and then again on CI. That way, you get all the benefits on CI, but can optimize for speed by installing pre-commit locally (and run either the exact same or a subset of checks).