To git hooks, or not to git hooks: that is the question

ca1989

Hi all,

as per title, I am considering the possibility to add git hooks to a Phoenix project.
We are a team af a few people (< 10) with the same editor setup.
No CI workflow is present at the moment.

That is why I would like to add git hooks, do you have advices on which checks to run and when?

I would love for them to don’t get much in the way (for example, when prototyping features on temporary branches).

I thought about this:

mix clean && mix compile on push
mix format on commit (is that a good idea to format files in place on commit? Running --check-formatted could be too annoying)
mix credo and mix test as responsibilities of developers

I’d love to hear from you
Kind Regards

15 comments

/phoenix #git #hooks

2 3646 15

2022-05-18 13:06:45 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

hauleth

Start with solving that.

IMHO commit hook should not modify code.

Post #1

crova

You might want to look at ex_check | Hex.
You could put that on your hook.

Post #2

al2o3cr

I’m curious about the motivation of this step; why would somebody be committing code that doesn’t compile? If it doesn’t compile, it can’t run in tests or even with manual prodding.

Post #3

szsoppa

Hey! There is a cool lib for that - helps maintain the proper “local CI” (Git hooks) for all of the devs in the project: GitHub - qgadrian/elixir_git_hooks: 🪝 Add git hooks to Elixir projects · GitHub.

Post #4

benwilson512

Author of Craft GraphQL APIs in Elixir with Absinthe

FYI this will be a real pain the first time somebody on your team needs to push up code that won’t compile so that a team member can help them.

I agree with @hauleth, this is the problem to solve. You can put specific rules about specific branches, rules about how PRs get merged etc, and it lets you handle mix credo and mix test centrally too.

Post #5

ca1989

In our setup you have to run tests manually. If you forget to run them you could very much commit code that doesn’t compile

Which is the reason I thought about git hooks

Post #6

ca1989

Thank you all,
setting up a CI seems the most logical first step to make.

Post #7

eahanson

I have a shell script in every project I work on called bin/dev/shipit.

It does all the things such as:

runs tests
runs dialyzer
runs mix audit
runs the formatter

If all those things pass, then it pushes. It’s very simple but it works (if everyone remembers to run it instead of just git push). If you for some reason need to push with one or more of those steps failing, you can just not run the script but instead just run git push.

Post #8

tfwright

I am strongly against imposing workflows on developers collaborating on a project. Everybody has a different order/process for producing code that is ready for review, and until its ready for review (and CI) all barriers and challenges should be minimized. If part of your process is to autoformat your code on every commit using a git hook, by all means do that, but please, please don’t impose that on your fellow devs who do not want to think about formatting at all until everything is ready.

Post #9

gregvaughn

I like writing a custom mix ci task/alias. The CI server should be configured to execute that, but also each developer can choose to run that on their own machine in case they need help diagnosing a problem that only occurs on CI.

Post #10

Load more posts (5 remaining)