CaptainHook is a very flexible git hook manager for software developers that makes sharing git hooks with your team a breeze.
This release focuses on cleaning up the installation and plugin confusion. From this point forward the captainhook/composer-plugin is deprecated and "replaced" by captainhook/hook-installer.
The decision was made because the composer-plugin package was doing too much. And by requiring captainhook directly it did not give you the opportunity to choose the CaptainHook installation method yourself.
The new hook-installer package is only focusing on the functionality of activating the hooks for all your team members.
Especially because of an issue @Eydamos pointed out. The Composer "script" solution has some serious drawbacks when installing dependencies with --no-dev. You can follow the discussion over here.
From now on, to automate the hook activation, you should combine your preferred way of installing the Cap'n with requiring the hook-installer package.
Installing the Cap'n as PHAR via Composer
{
"require-dev": {
"captainhook/captainhook-phar": "^5.19",
"captainhook/hook-installer": "^1.0"
}
}
Installing the Captain's source code and its dependencies with composer.
{
"require-dev": {
"captainhook/captainhook": "^5.19",
"captainhook/hook-installer": "^1.0"
}
}
Installing the Cap'n via PHIVE and the hook-installer via composer.
{
"require-dev": {
"captainhook/hook-installer": "^1.0"
},
"extra": {
"captainhook": {
"exec": "tools/captainhook.phar"
}
}
}
If you use Docker to execute the captain until now you could run into problems by using git commit -a.
The reason being that git uses an environment variable to configure the index file to use.
The command git commit -a creates a new index file with everything in in it not changing your original index before the command succeeds.
So for this to work, the GIT_INDEX_FILE environment variable hat to be forwarded to the Docker container. And more, since the variable contains the path to the index file the path had to be mapped from the host system path to the container path.
This is now all done by the Capn, but only if you specify the run-gitconfig value with the path to the.git` directory within your container.
Here is an example configuration:
{
"config": {
"run": {
"mode": "docker",
"exec": "docker exec my-container",
"path": "vendor/bin/captainhook",
"git": "/docker/mx-project/.git"
}
}
...
}
For hooks that could need the environment variable like pre-commit this will result in Docker command like this:
docker exec -i -e GIT_INDEX_FILE=/docker/my-project/.git/($GIT_INDEX_FILE) my-container vendor/bin/captainhook ...
So from version 5.18.0 the Cap`n tries to optimize you docker commands. If you run in any problems let me know.