dx: Add pre-commit as a central linter, formatter and checker#7884
dx: Add pre-commit as a central linter, formatter and checker#7884rustyrussell merged 1 commit intoElementsProject:masterfrom
Conversation
By limiting the commits that we look at to the changes since `master` we can incrementally pull files under the coverage of these lints and checks. Changelog-None: Not applicable, this is DX
|
I see |
|
Whoops? What is flake8 doing with the Makefile? Presumably it fails to parse it as python? |
I should have phrased my comment more clearly. I see the |
|
Oh, I see. The intention is to use one l'Inter per language. Otherwise we might get into a territory where they disagree causing unresolvable lint warnings. Let's remove flake8 altogether. |
|
For others reviewing this PR, here is another demo PR against the original branch containing some initial |
|
Good start! Let's merge this so we can build on it! |
3 participants
We have quite the variety of different formatters, checkers and linters:
shellcheckrun viamakecheck-amount-accessgrepping for access to theu64inside of theamount_msatandamount_satstructs.discouraged-fundctionscheck-gen-updatedcheck-includescheck-src-includescheck-hdr-includescheck-hsm-versionscheck-manpagescheck-spellingcheck-whitespaceFor many of these we have custom scripts that require us to maintain
them as well, despite there being off-the-shelf tooling that allows us
to check and enfore these.
pre-commitstandardizes the execution of these checkers, runningthem against the proposed changes in a PR. It allows for checking and
fixing as separate steps, so CI can just check, and show the diff of
changes that would have been applied.
The
--from-refand--to-refparams help us to limit the scope ofthe checks to the proposed changes, allowing us to incrementally adopt
these standards as we visit the files.
If you adopt a new file, i.e., modify a file that has not been checked
before, you might want to just quickly run
pre-commit run --from-ref=master --to-ref=HEADafter the first modification, and fixup any lints or failing checks before moving on to actually
implementing your changes. This keeps the lint cleanup separate from
logic changes that are to be reviewed.