OCamlformat and GitHub actions

Community
,
1

Dear everybody,

a small announcement for those using OCamlformat in their projects: if you find the burden on external contributors very high, and always express “please run ocamlformat on your PR” – we’ve been in the same boat.

We developed a GitHub action which automatically runs OCamlformat and pushes that on the PR. No need for contributors to remember running OCamlformat, no need for “OCaml-CI” to fail since ocamlformat run diverges.

If you’re interested, take a look at mollymawk/.github/workflows/format.yml at main · robur-coop/mollymawk · GitHub – please note that we use find . -name \*ml -maxdepth 1. EDIT: as @nojb suggested, we use git ls-files now :tada:

Happy to share this action which turned out to be tremendously useful for some of our projects (github).

Have a nice day :smiley:

14 Likes
2

Thanks, sounds useful!

Incidentally, at work we have something similar, and we use git ls-files '*.ml' '*.mli' to fetch the list of files. It is very fast and ignores everything that is not committed.

Cheers,
Nicolas

3 Likes
3

Thanks, I opened a PR for that. indeed, the git ls-files sounds like a great idea (and doesn’t need to mess around with find, -maxdepth and -not -path ... (which seems to be highly importable across GNU find and BSD find)).

5

Thanks for the pointer. Indeed I’m aware of pre-commit and have contributed to code basis where it is used a lot.

I still find it is a burden on the person wanting to contribute to have to install some arbitrary python software and dependent docker containers that run the hooks - esp. since that works only on certain operating systems.

The approach outlined above does remove the burden on the (potential) contributor, and let GitHub action do the tedious work of formatting the code and pushing a commit. Of course if the developer wants to change something, there’s a commit to be pulled first (or a force-push is needed).

After all these years of OCaml-CI “fmt job” complaining with a diff about badly formatted code, I find the GitHub action workflow a big relief. I also understand that other people/organizations/projects prefer other (or no) means of formatting code, including “CI is failing, please run dune build @fmt”, “install pre-commit and our 25 docker containers”, “we don’t care about code formatting” - and likely a dozen other approaches. Our shown GitHub action is not what we want to impose on all OCaml projects, it is just an option - and took us some hours to write this YAML file.

2 Likes
6

I didn’t realize that it is this easy to modify PRs from within the CI, thought you’d have to write and register a github application. Nice solution!

1 Like
7

Looks amazing, thanks!

The generated commit will mention robur and has an email, set in

I’d like to start using this code in my projects. And I’m happy to have the commits credit you. But are you ok having those info appear in random other projects or would you prefer if we change them?

1 Like
8

Thanks for your interest. Do as you like. The email addresses bounces anyways (and there’s no GitHub account connected to it) – depending on your project, you may want to use another commit author.

Credits can be given by GitHub staring our repositories, or donating. :smiley:

1 Like
9

I dislike these shallow reformat commits and would rather have the bot rewrite history, which may be possible in simple cases. Conflict can be solved by keeping the latest side of the merge (theirs in Git terminology, if I’m not mistaken) and re-running OCamlFormat. I often run git rebase origin/main --exec 'dune fmt'.
As an extension, you could suggest to add the id of the reformatting commit to the list of commits to be ignored by git blame, see how-to-git-blame-ignore-revs.md.

10

I understand. This list to-be-ignored by git praise is a good idea.

Of course it depends on your merge style, and if you squash-merge anyways, it doesn’t matter.

But surely, you could replace the git commit with a git commit --amend and use a git force-push.