feat: Startup script + local git hooks

[JohnnyGuye]

Added a small startup script in bash that currently does two things:

• checks the tools mandatory for the project (node/npm, cargo, docker) so you can get them quickly if you don't have them
• install locally a git hook on commit-msg so you know when you don't meet conventional commits before the PR

[Lauwed]

Please run npm audit fix to fix the version of the dependency micromatch

[ferdodo]

Adding a script to install git hooks makes sense 👍

The commit check from the bash script doesn't respect the conventionnal commit convention as defined in the ./git-conventionnal-commit.yaml at the root of the project, meaning we can have some conflict between local check and github actions check.

how about running docker compose run web npx git-conventional-commits commit-msg-hook last-commit-message from the commit hook (with some way of retrieving the current commit message) ?

That way you need to rewrite the commit message check itself.

[ferdodo]

"startup" might be a bit misleading, as the script doesn't startup the application.

What do you think of separated concerns and explicit names

./setup-git-hooks.sh
./check-tooling-version.sh

[ferdodo]

We can merge the commit message check as is. I'm just adding this comment for starting a review for renaming bash scripts.

[JohnnyGuye]

@ferdodo

Quick direct answers:

"startup" might be a bit misleading, as the script doesn't startup the application.

Agreed. I did that on my computer before seeing your reviewed changes so I'm shipping them from my commit.

What do you think of separated concerns and explicit names

./setup-git-hooks.sh ./check-tooling-version.sh

I would do that for almost any other language, but I'm not really on this boat for a shell script that is this short.

how about running docker compose run web npx git-conventional-commits commit-msg-hook last-commit-message from the commit hook (with some way of retrieving the current commit message) ?

I don't like the idea of having "advanced" tools within a commit hook.

Lengthy reasoning

The goal is to have a script that runs on any computer with the lowest amount of tools and the lowest amount of additional steps if doesn't work out.

• The choice of shell script is because it works natively on MacOS/Linux and if you installed git you probably already have a bash command tool.
• Single file is so you can just give the exec rights to this one file and it will work just fine if you have to do it.
• Similarly, the commit hook doesn't use any other tool than bash so you can still commit even if you don't have anything else installed (notably, if we have people just participating as artists, they clearly don't care about running node/docker/cargo and I don't want to miss on their participation because of that)

So I'm losely against the separation of concern, you can change my mind easily tho, especially because i'm not versed in shell scripts. And in any case, I will add documentation in the script to make it easy to navigate.

I'm really against running any other tool within the hooks because it makes commits reliant on the accessibility of the tool. An alternative would be to generate the commit hooks from the yaml so they stay in sync whilst not using anything when in use.

[ferdodo]

I agree with you on using bash scripts over nodejs tooling.

Separating scripts is mostly for reusability, the ./check-tooling-version.sh could be used to enforce versions for actions and prod env, and container build context too.