dx: Add pre-commit as a central linter, formatter and checker #7884
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:
shellcheck
run viamake
check-amount-access
grepping for access to theu64
inside of theamount_msat
andamount_sat
structs.discouraged-fundctions
check-gen-updated
check-includes
check-src-includes
check-hdr-includes
check-hsm-versions
check-manpages
check-spelling
check-whitespace
For 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-commit
standardizes 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-ref
and--to-ref
params 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=HEAD
after 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.