dx: Add pre-commit as a central linter, formatter and checker #7884
+13
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.