Discuss add pre-commit with python and ts/js formatters and linters
Description
pre-commit is a tool to run checks and the normal usage is to hook it into git so that it gates commits until they pass checks. Checks are only run on changed files (when using git hooks). I believe it’s used on a number of projects already.
I like to think of it as a local CI phase that runs checks that are in the realm of seconds, with the MR/PR/feature branch checks/tests being in the range of minutes. The earlier we can fail, the cheaper the fix.
A lot of pre-commit checks are also fixers (e.g. black, prettier, eslint). My typical workflow is to write code that black then fixes via pre-commit, running my commit once failing and running it again with it passing.
Q. Will developers have to use pre-commit?
Technically no as each of the checks can also be run directly/manually, via IDEs or just the CI run. It can instead then be seen as just a directory of checks that need to met. The cli can also be run manually and not connecting to the git hooks.
I'm going to suggest we only add checks that bring their own dependencies and have no additional steps (first usage will install dependencies in venvs/node_modules/docker/etc). This can be done with most well used checks and more niche checks can be tweaked to use docker to achieve the same.
Suggested initial tools:
-
default pre-commit checks
-
black + isort
-
flake8
-
eslint (fixer on)
-
prettier (via eslint)
Example config for this is here: https://gitlab.developers.cam.ac.uk/uis/devops/laboratory-allocator/lab-allocator/-/blob/main/.pre-commit-config.yaml
Future tools if adoption successful:
- dockerfile linter (conventions, lean images, pinnig, etc.)
- terraform linters (conventions and security)
- secrets scanners
Acceptance criteria
Creation of new tickets to add pre-commit or the decision to not add pre-commit.