Git Hooks

Whilst in the Frontend we are leveraging Husky, we are not really leveraging node in the backend, this is entirely a .NET Solution. And so, we won’t leverage that specific tool. In its place we will leverage Git Hooks, Husky is a wrapper around git hooks by the end of the day.

Whilst husky helps bridging the gap between UNIX and Windows workstations, we have to setup a bit further when using raw Git Hooks since depending on the OS the commands that run will not work on a case-by-case basis.

This is the order of steps used to setup a new hook:

  1. Create a hook file at kakeibro-api/git-hooks/

  2. You can test if the hooks are working as intended by running git commit --amend --no-edit followed then by git push --force (you could also just roll-back if you don’t want to push anything).

Make sure you have run the Onboarding first, otherwise none of the things stated further will work as intended.

Git hooks can insert themselves in different stages of the commit lifecycle, we are at least for the time being leveraging pre-commit and pre-push, which before letting us actually save the commit to VC it will police our changes.

The pre-commit hook we have at the git-hooks folder of the repository is cross-platform, it will run both on Windows and Linux, depending on the OS it will then execute either pre-commit.sh or pre-commit.ps1.

The post-commit hook we have at the git-hooks folder is also cross-platform and will execute the respective script based on the OS.

The pre-push hook we have at the git-hooks folder is also cross-platform and will execute the respective script based on the OS.

It’s worth noting that the moment a hook runs, its executing path will be the root path at which we have the .git folder. Meaning that based on that starting point all the logic we set in place should be built accordingly.

Windows Setup

All logic specific to Windows, will make use of powershell, so any commands specific to that CLI are present in here.

The pre-commit.ps1 script takes care of doing the following tasks:

  • Checking code format (according to conventions)

  • Building the solution

  • Running all tests

  • Running appsettings.json OAuth credential sanitization by blanking out sensitive fields, and backing up the contents for the post-commit hook to then finish this specific flow

The post-commit.ps1 script takes care of doing the following tasks:

  • Work in conjunction with the pre-commit.ps1 file so that once its backup appsettings.json contents are saved in a different file, this then restores all of that into the original appsettings.json file and deletes the backup file

The pre-push.ps1 script takes care of doing the following tasks:

  • Checking code format (according to conventions)

  • Building the solution

  • Running all tests

  • Running a check for possibly outdated packages

    • NOTE: This will never fail, the command only lists out its findings, a good still to let people know as they work that something might need an update.

  • Running migrations (TBD: This requires for Entity Framework to be installed and setup up in a specific project(s))

  • Running a check on possible vulnerable packages

The difference between the amount of operations each stage has has been configured with intent. Whilst simply comitting we shouldn’t have to disrupt the developer experience as much since changes might get overwritten later, and the flow state might end up taking a hit. However, before trying to push something to version control we will run as many checks as we can so that we are not pushing bad code that could end up breaking the build.

Linux Setup

All logic specific to Linux, will make use of bash, so any commands specific to that CLI are present in here.

The pre-commit.sh script takes care of doing the following tasks:

  • Checking code format (according to conventions)

  • Building the solution

  • Running all tests

The pre-push.sh script takes care of doing the following tasks:

  • Checking code format (according to conventions)

  • Building the solution

  • Running all tests

  • Running a check for possibly outdated packages

    • NOTE: This will never fail, the command only lists out its findings, a good still to let people know as they work that something might need an update.

  • Running migrations (TBD: This requires for Entity Framework to be installed and setup up in a specific project(s))

  • Running a check on possible vulnerable packages