try pre-commit.ci?

[minrk]

The author of pre-commit is building pre-commit.ci, a CI service just for running pre-commit. The main thing it adds over our custom pre-commit runs is that it will automatically push a fix commit to PRs if needed, so that nobody needs to fix their own linter errors (assuming they are fixable like formatting). It also apparently can be faster, since it has environment caching designed for pre-commit. Plus it will do dependency bumps for pre-commit hooks like dependabot for other dependencies.

Should we give it a try, maybe just on e.g. z2jh which has the most pre-commit config at the moment?

[consideRatio]

Sure! I figure that regular developers will learn to install the pre-commit hooks and never need it, while non-regular developers will benefit from getting the fix applied.

I guess the downside would be if you push, dont think about it, and then push again with a conflict and need to figure out what has happened.

[choldgraf]

this sounds great

[minrk]

push again with a conflict and need to figure out what has happened.

Yes, though it's always fine to push -f and overwrite the CI-generated commit, since it will just fix it again if needed. Of course, the folks most likely to face this are also the folks least likely to be confident in their use of push -f. But we can help them!

I think it will be a good experiment to see if it's more or less disruptive to have these auto-fix commits. I'm not sure, honestly, but I am hopeful.

[consideRatio]

While I was initially hesitant on using pre-commit.ci for the same reasons raised by @betatim:

Can we run the pre-commit checks in GH Actions instead of adding yet another CI provider? The more different providers we use the higher the chances that one of them has an outage, makes changes we have to react to, etc. GH Actions seems to be running well and we use it a lot, so if we can get the tools/checks executed there that would be a win if you ask me.
--- @betatim in jupyterhub/binderhub#1381 (comment)

I've changed my mind though.

1. Some repo's used a pre-commit github action that was deprecated in favor of pre-commit.ci
2. I've found pre-commit.ci to be lightning fast
3. I've appreciated pre-commit.ci's weekly automatic PRs to update the versions of hooks in .pre-commit-config.yaml
4. I've found the automatic pushes of commits fixing fixable issues to be positive. Initially I was hesitant, thinking it could be disruptive to have commits added to ones PRs and not worth the benefit of getting them. I now like it having been able to merge basic PRs faster thanks to the simple autoformatting fixup commit added automatically.

[choldgraf]

We've used pre-commit.ci in the executablebooks repositories and I think that it is really helpful. For one thing, it makes it easier to make edits / propose changes to a repository directly from the web UI of GitHub. Before we used it, people would often make a PR via the GitHub editor, but forget to do something like remove trailing whitespace. Then the PR would fail pre-commit tests, and the person would have a major extra hurdle of needing to clone locally, fix, run pre-commit, etc. With pre-commit.ci it "just works" and very quickly at that.

So in short, I have grown in my appreciation of this service and am a stronger +1 on using it.

[betatim]

Sounds like we should give it a try

[consideRatio]

I'm very happy about pre-commit.ci overall and look to see it adopted in our github org generally!

[minrk]

Yup, I think we can call this a success