Enable common pre-commit.ci fixes

[nyurik]

ATTENTION admins: I don't see pre-commit in the list of actions that ran on this PR - perhaps it was never enabled? https://pre-commit.ci/

Pre-commits are usually used to minimize busy work by the contributors, e.g., by fixing extra spacing, formatting, etc. This PR adds various basic text file checks to the repo. I copied these settings from many other projects I maintain - they have proven to be fairly useful. I also made yaml spacing a bit cleaner.

I was a bit surprised it is used for cargo clippy because you wouldn't want clippy's auto-fixes to be auto-applied by CI, so usually GitHub workflow simply runs it as a regular step. This is outside of the scope for this PR, but perhaps it should be removed here?

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)

[sylvestre]

yeah, maybe add it to the CI ? :)
thanks

[tertsdiepraam]

I think the pre-commit was meant for local use? The rest of the CI contains all the necessary checks.

[nyurik]

The whole idea of the pre-commit CI is to simplify contributions, esp from new users, without asking them to fix minor annoyances. Main idea: whenever PR is created, precommit.ci runs a few basic checks, fixes many simple ones like line endings and cargo fmt, and pushes the change directly to the PR -- without requiring the user to wait for CI to reject things, fix a few spaces by hand, and resubmit.

This is very different from the pre-commit git hooks - which run locally, but require the user to have all the right tooling setup. This is also different from the usual github CI - because github requires more involved setup and does not usually modify a PR.

We have had it enabled at MapLibre org for a long time, same for Varnish-rs, PMTiles-rs, and many other projects I maintain or contribute to. It simplifies the barrier of entry without annoying newcomers.

Here's the typical example: maplibre/maplibre-tile-spec#485

• A new user contributed some documentation change
• pre-commit noticed that there are trailing spaces and removed them - without requiring the user to do that
• maintainer simply merged the result

If CI was used, the user would have had to wait for CI to finish, see failed CI, modify the contribution and resubmit -- resulting in fewer contributions overall.

[tertsdiepraam]

I understand and I see why you would want that, but I personally don't like it when CI changes my code (and adds commits and all that). I was also remarking that you are taking the existing pre-commit that people might rely on locally and changing it for use in CI.

[nyurik]

@tertsdiepraam to be honest, when someone showed it to me, I was also not excited until I saw how much work it helped with, and how much more smooth the onboarding of new contributors have become. As for changes - I don't think my changes will affect local usage because the repo flag is not set to local - so local usage will simply ignore the new section.

[tertsdiepraam]

Ah I see, I misread the diff. Apologies!

[nyurik]

No worries. Here's a even better example for my Martin project which has gained 9 new contributors for the last version alone -- this person is contributing some SQL code, and pre-commit reformats their SQL code on the fly into "project style" without requiring anyone to install the specialized tooling and without blocking any development and without nagging.

maplibre/martin#1868