Open chouinar opened 1 month ago
Looking into this a bit, we actually hav a pre-commit config at the root of the repo already, although very little configured within it.
A very rough approach we might take for running our make commands is adding something like:
- repo: local
hooks:
- id: api-custom
name: API linting
description: TODO - the api linting
entry: make -C api lint
language: system
types: [python]
pass_filenames: false
files: api/
Naming aside, this makes it so when you attempt to do git commit
, it runs the given make command. In this case, if I have something invalid in the file format, the linter will complain when I try to commit. You can work around the checks entirely by doing git commit --no-verify
Also, by specifying the folder, it only validates if there are changes to that folder (we could make it more specific if desired).
Pre-commit doesn't support monorepos intentionally https://github.com/pre-commit/pre-commit/issues/466. Wasn't able to get things working with the make -C frontend lint
as it complains there is rule and doesn't look like it is able to change the directly through the make command.
It sounds like monorepos are supported sort've - depends how much you want to put in the pre-commit config. If you have multiple sub-folders you'll need to duplicate a lot with different commands/file paths. Specifying the file path determines what changes trigger pre-commit to even run for a given folder.
A rough approach that might work flexibly and keep the pre-commit file simple is to have a bash script in each sub-folder that the pre-commit calls. The command can be the equivalent of cd api/
and ./pre-commit.sh
- where the shell script has all the make commands and other stuff you might care about.
Summary
First figure out what tech we use (pre-commit or something else).
This should run the following commands locally (making a single make command that does all of these might be better -
make check
does most of this):make format-check
make lint
make db-check-migrations
make lint-security
make test
Whatever approach we take should be skippable to avoid blocking someone making a branch that they can share without being 100% valid.
Acceptance criteria