Running Hooks in Subrepositories fails

[norgeindian]

We have some difficulties in setting up captainhook for subrepositories in our project. Let me explain our project structure:

We have the captainhook.json in our project root folder. The config looks like this:

    "config": {
        "run-mode": "docker",
        "run-exec": "docker exec -i project-php-fpm-1"
    }

And that works fine. When I run captainhook install, for example, the .git/hooks/pre-push looks like that:

docker exec -i project-php-fpm-1 vendor/bin/captainhook hook:pre-push --bootstrap=vendor/autoload.php "$@"

So far, so good. Now we have a git sub structure in vendor for modules, where we would like to run hooks as well as soon as we push something. We don't want to add a captainhook.json for each module, but reuse the existing one from the project, as the actions are the same. I installed the hooks inside our docker container with the following command:

../../bin/captainhook install --configuration /var/www/html/captainhook.json

The content of the generated pre-push file in the submodule is the following:

docker exec -i project-php-fpm-1 /var/www/html/vendor/bin/captainhook hook:pre-push --configuration='/var/www/html/captainhook.json' --bootstrap=vendor/autoload.php "$@"

In my eyes, that looks fine as well. When I run exactly this command in the CLI, it runs the wanted tests and everything is fine. Unfortunately, it does not work properly, when I push. In this case, I only get the following error:

pre-push:
captainhook failed executing all actions, took: 0.01s
error: failed to push some refs to 'bitbucket.org:xxx/yyy-module-zzz.git'

Any idea, what I could try? Also, verbose mode does not really show more. Is there any good way to debug that?

[norgeindian]

I checked that further and found out, that it is not related to the general setup, but to the actual tests we're running. We're using a condition for phpcs to only check files changed of type PHP. As soon as I remove this condition, the hook works fine. Is there a good explanation for that?

[sebastianfeldmann]

The Cap'n needs git to figure out the changed files. Is git available within your container and has access to the .git directory?

[norgeindian]

@sebastianfeldmann, thanks for your reply. I don't see a reason why the captain should not have access. Like I said, when I run the command manually, there is no problem.

I now debugged into \CaptainHook\App\Hook\Condition\FileChanged\OfType::isTrue, which is in my eyes the problematic point. I "var_dumped" the $repository during the push of my sub-repository changes, and see the following:

That seems to be the project repository and not the sub-repository in the vendor folder. How does the captain decide, which repo to take? As I push my sub-repository, I would expect him to use this one.

[sebastianfeldmann]

🤔 I never worked with submodules

So normally the Cap'n looks for the default path ./.git. You can specify a custom path to your .git directory.

--

So i played around with submodules a little bit. Adding a submodule to a repository adds a git-directory in your git-directory normally unter .git/modules/MODULE_NAME

You have to install the hook there as well to .git/modules/MODULE_NAME/hooks

In my tests the captainhook install command did not work properly. Only adjusting the hook scripts manually made it work. I will try to figure out a way to make the install command work properly.

Here is my manually adjusted pre-commit hook script for my submodule, the important parts are the ../ in front of the command and the configuration option.

#!/bin/sh

# installed by CaptainHook 5.23.0

INTERACTIVE="--no-interaction"

# read original hook stdIn to pass it in as --input option
input=$(cat)

if [ -t 1 ]; then
    # If we're in a terminal, redirect stdout and stderr to /dev/tty and
    # read stdin from /dev/tty. Allow interactive mode for CaptainHook.
    exec >/dev/tty 2>/dev/tty </dev/tty
    INTERACTIVE=""
fi

../vendor/bin/captainhook $INTERACTIVE --configuration=../captainhook.json --bootstrap=vendor/autoload.php --input="$input" hook:pre-commit "$@"

[sebastianfeldmann]

If you run the install from the submodule the Cap'n will figure it out.

../vendor/bin/captainhook install --configuration=../captainhook.json

The only disadvantage I see is that the Cap'n copies the absolute path from the submodule .git file similar to additional worktrees. This means you can not move your project to another directory without re-installing the submodule hooks.

[norgeindian]

@sebastianfeldmann, thanks a lot for your help and investigation here. I fear I did not explain our setup properly enough. Thought, it would be unimportant, but it seems to make a difference. The modules, I'm talking about, are no proper git submodules. They are included via composer, but required with the --prefer-source flag. So they live, like normal composer requirements, in vendor, but they include a .git folder on their own. You can reproduce that with any composer module, just run composer require XXX --prefer-source. And for these, we would like to have the same hooks as we have for our composer project. Would you be so kind and try that with your approach? I think, there, you will have the same problem as I mentioned before. Please let me know your findings. Thanks a lot again for your help here, I know, this is a pretty rare and unusual case, we have here, but we did not find any other way for our project.

[sebastianfeldmann]

So here is how you can do it:

My file structure looks like this

tools
├─ captainhook
vendor
├─ namespace
│  ├─ package
│  │  ├─  .git
│  │  ├─  ...
├─ autoload.php
captainhook.json
composer.json

when inside vendor/namespace/package run

../../../tools/captainhook install --bootstrap ../../autoload.php

this requires the package to bring their own captainhook.json.

If you want to use the same config as the main project you have to reverence the config and adjust your bootstrap path

../../../tools/captainhook install --configuration=../../../captainhook.json --bootstrap=vendor/autoload.php

because the bootstrap path is checked from the configuration location.

[sebastianfeldmann]

Another option is to run this command from the main project root.

tools/captainhook install --git-directory=vendor/namespace/package/.git

All of them worked on my machine ;)

[norgeindian]

@sebastianfeldmann, thanks a lot for your help here. Really awesome. I just tested, and your last approach seems to work fine for us, and it looks a bit easier than the first one. Again, thank you so much. Will let you know, as soon as something strange comes up in that process.

[sebastianfeldmann]

Perfect, I will close this. Feel free to reopen it if you encounter any problems :)