About the post-install-cmd example and installing with --no-dev about composer-git-hooks

[dylan-kerr]

I ran into this same issue and wasn't 100% happy with the solution above as it is not portable across shells (both PowerShell and Bash, in my case). I solved it by adding a script that skips the following scripts in a non-dev install:

src/Utility/ComposerScripts.php

<?php

namespace Utility;

use Composer\Script\Event;

class ComposerScripts
{
    /**
     * Run scripts that follow only if dev packages are installed.
     */
    public static function devModeOnly(Event $event)
    {
        if (!$event->isDevMode()) {
            $event->stopPropagation();
            print("Skipping {$event->getName()} as this is a non-dev installation.\n");
        }
    }
}

composer.json (excerpt)

{
    "autoload": {
        "psr-4": {
            "Utility\\": "src/Utility"
        }
    },
    "scripts": {
        "post-install-cmd": [
            "Utility\\ComposerScripts::devModeOnly",
            "cghooks add --ignore-lock"
        ],
        "post-update-cmd": [
            "Utility\\ComposerScripts::devModeOnly",
            "cghooks update"
        ]
    }
}

[dylan-kerr]

Simi: the approach I suggested on this issue a couple of months ago uses a custom ComposerScripts class is fully cross platform and tested on Windows, so that might be worth trying.

…

On Fri., 7 Feb. 2020, 15:26 Simi Oluwatomi, ***@***.***> wrote: I think I'll just install it as a normal dependency. I'll think of something later. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#100?email_source=notifications&email_token=ACC7DX4MQJUCGLVJLXRY5OLRBV4UBA5CNFSM4JAQLRH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELDMK7I#issuecomment-583452029>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACC7DX44V5UIGTDB5ABXGLTRBV4UBANCNFSM4JAQLRHQ> .

[devnix]

It's working now. Thank you!

[devnix]

@devnix you can use composer update nothing this command will not update your packages untill you have changes in your composer.json

Yeah, but I guess the whole point is to integrate git hooks into your Composer workflow, and not to modify it 😄

[devnix]

Oh damn, sorry, didn't saw the last line. Maybe you could try MYSYS or an equivalent Windows command? I think this would be out of the scope of this repo

[bbetter173]

Here's my solution, though it's linux only:

"scripts": {
	"cghooks": "app/Vendor/bin/cghooks",
	"post-install-cmd": "test -f app/Vendor/bin/cghooks && app/Vendor/bin/cghooks add --ignore-lock || true",
	"post-update-cmd": "test -f app/Vendor/bin/cghooks && app/Vendor/bin/cghooks update || true"
}

[leymannx]

Problem might be that remove creates a lock file if running in that order. See #119.

Seems you are safer having it more like @HeWhoWas has it, and maybe even prevent the lock file from being created at all:

"scripts": {
	"post-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks add --no-lock",
	"post-update-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks update",
}

[BrainMaestro]

@devnix the idea for the cghooks.lock is that it represents the local state of your git hooks. Imagine that the file is committed and a new developer start working on the project. Their hooks will not be installed correctly. The fix for .gitignore can be done by appending a blank line as well.

The --no-dev feature was reverted, so, yes it does not work. The previous implementation did not work as expected. I have just updated the release note from 2.7.0 to make that clear. Also, you shouldn't need to specify .git, that's kind of strange. Could you create a reproducible repo so I can take a look? When you have time of course.

Thanks for the feedback!

[devnix]

Hi @BrainMaestro!

I get the point of the lockfile, maybe I did not explain it correctly:

Let's imagine that I configure the "post-install-cmd": "cghooks add --ignore-lock" line, and I run composer install. cghooks will modify my .gitignore by adding a new line with the lockfile.

Now, my coworker does a composer install too. As he still does not have any lockfile, cghooks will modify my .gitignore again. This will occur each time someone configures a new workspace of the project.

That's why I'm suggesting to rethink the behavior or, at least, the recommendations on the readme file.

The example I provided on the first post solves this problem, and the --no-dev problem too.

I'm not worried about the .git problem because it's a strange environment, but if you are curious, it happened on a container based on this:

FROM php:7.0.27-apache

RUN apt-get update && apt-get install git -y

I found that the git rev-parse --git-common-dir command gives an empty output inside that container (with my volume setted up)

[BrainMaestro]

Oh right, now I understand. We should actually check the lockfile first before doing the modification. Would you be interested in doing a fix? It shouldn't be too tricky unless we do more sophisticated matching. The alternative which is not to have --ignore-lock would likely cause accidental commits and mess up the git hook generation for new users. I think I still want to keep the recommendation

For the docker issue, it's because the version of git installed in the container is quite old (2.1.4 - released in 2014) and does not understand the --git-common-dir output. This can be fixed.

[BrainMaestro]

Actually, I just checked, and this lockfile behavior (checking if it already exists in the .gitignore) is already present and should work correctly after #98. I made a commit to fix the --git-dir problem. Maybe you can install dev-master and see if it solves the issue for you? As for the last one (needing command -v), I'm not sure of how to handle it

[devnix]

Yes, cghooks checks if exists a lockfile, and then adds the lockfile to the gitignore. The problem is that if another person checks out the project, cghooks will not detect any lockfile, and will add a repeated line to the gitignore. This will happen every time you execute composer install with the --ignore-lock configuration.

The solution would be to manually modify the gitignore, or parsing the gitignore to avoid duplicating the line.

[devnix]

By the way, adba29a seems to work like a charm!

[devnix]

Oh, okay, just found your strpos check, you were meaning that, right?

[BrainMaestro]

Yes, looks like it's broken though

[BrainMaestro]

Can you try f90b682? should work now

[devnix]

vendor/bin/cghooks add --ignore-lock still reports You did not specify a git directory to use, using dev-master f90b682

[BrainMaestro]

But I thought you said it worked before?

[devnix]

By the way, adba29a seems to work like a charm!

It seems like I accidentally ran my old composer script with the --git-dir 🤦‍♂️

[BrainMaestro]

Can you run git rev-parse --git-common-dir and git rev-parse --git-dir and let me know what they return?

[devnix]

www-data@b7b360a4808d:~/html$ git rev-parse --git-common-dir
--git-common-dir
www-data@b7b360a4808d:~/html$ git rev-parse --git-dir
.git

[BrainMaestro]

Okay as expected. I found the bug in the function, so it should work now. 🤞

[BrainMaestro]

Okay great, can you test the --ignore-lock behavior? If all is good, I'll make another patch release

[devnix]

I tested it too, and I think it's working fine!

[BrainMaestro]

Okay, great. if you have any ideas for avoiding the command -v pattern, let me know. I'll close this issue now and create a release. Thanks for the help

[BrainMaestro]

@devnix, you can use the new release https://github.com/BrainMaestro/composer-git-hooks/tree/v2.8.2 now

[devnix]

The only idea I have is to uninstall and reinstall the hooks every install. Also, I would expect to update the hooks with a simple composer install.

Bundling the update of hooks with composer update is forcing you to upgrade your composer packages, which is an operation completely unrelated to my point of view.

The neatest workflow I can imagine is to do only install and uninstall operations even without a lockfile, but I fully understand that this idea may conflict with the established philosophy of the project, and would break backwards compatibility.

[aman00323]

@devnix you can use composer update nothing this command will not update your packages untill you have changes in your composer.json

[BrainMaestro]

@devnix I understand the idea behind the lockfile and maybe I can actually get rid of it. I'll consider that for v3. However, I was specifically asking about the issue with needing command -v

[devnix]

@BrainMaestro Not sure, I'm still not 100% aware of the internals of a Composer plugin, but I guess that if the hooks are managed by the package automatically with the behavior I've proposed, it should work as expected even when switching the --no-dev flag on and off.

In fact, the composer.json would be even easier, por example:

{
    "require-dev": {
        "overtrue/phplint": "^1.1",
        "brainmaestro/composer-git-hooks": "^2.8",
    },
    "extra": {
        "hooks": {
            "pre-commit": [
                "./vendor/bin/phplint"
            ],
            "post-merge": "composer install"
        }
    }
}

[BrainMaestro]

The problem is as a dev dependency, cghooks won't even be installed in prod environments, so any cghooks command will definitely fail. --no-dev or not

[devnix]

Hm, I guess we could move our conversation to chat or email to avoid flooding the issue!

[devnix]

I'm looking forward to get some free time and try a new strategy purely based on a Composer plugin, without a CLI tool or a lockfile to maintain a list of hooks.

[BrainMaestro]

@dylan-kerr that's not such a bad solution. @devnix a composer plugin sounds like the right strategy. Maybe that can be adapted to this as a possible 3.0?

[simioluwatomi]

Great plugin here. I installed it into a project at work because I want our workflow to be more standardized. However, I am experiencing problems after running a deployment to production. This is because production servers install composer dependencies with the --no-dev flag.

Because I had to do the deployment, my temporary fix was to remove the commands I had setup.

What is the permanent fix that you suggest for those who install this in an environment with the no-dev flag?

Thank you

[devnix]

For me, my definitive solution was to hack my composer.json:

"scripts": {
	"pre-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks remove",
	"post-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks add",
	"post-update-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks update",
},

I will leave it like that until a new version is published fixing this behavior, or until I get some spare time to write my own implementation (not in the short term).

[BrainMaestro]

@simioluwatomi glad you like it. I would do as @devnix suggested or you can create a simple shell script that does the same (checks for whether cghooks is present and forwards the parameters if it is, and does nothing otherwise).

I haven't had the time to come up with a broader solution

[simioluwatomi]

@simioluwatomi glad you like it. I would do as @devnix suggested or you can create a simple shell script that does the same (checks for whether cghooks is present and forwards the parameters if it is, and does nothing otherwise).

I haven't had the time to come up with a broader solution

Thanks for the suggestion. but I'm no expert at bash scripting.

For me, my definitive solution was to hack my composer.json:

"scripts": {
	"pre-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks remove",
	"post-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks add",
	"post-update-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks update",
},

I will leave it like that until a new version is published fixing this behavior, or until I get some spare time to write my own implementation (not in the short term).

Thanks!!! But I keep getting The system cannot find the path specified. for all the scripts.

Maybe it helps if I mention that I am running on windows and use git bash.

[devnix]

Are you using Windows, @simioluwatomi?

[simioluwatomi]

Are you using Windows, @simioluwatomi?

Yep! I mentioned that earlier too

[simioluwatomi]

I think I'll just install it as a normal dependency. I'll think of something later.

[VanTigranyan]

Hey @devnix I have the same problem on the prod env, as we are running the command with --no-dev. Any updates here so far? I found nothing in the docs.

[devnix]

Hey @VanTigranyan, not really, no. I think for now this is the best solution:

For me, my definitive solution was to hack my composer.json:

"scripts": {
	"pre-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks remove",
	"post-install-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks add",
	"post-update-cmd": "command -v vendor/bin/cghooks >/dev/null 2>&1 || exit 0; vendor/bin/cghooks update",
},

I will leave it like that until a new version is published fixing this behavior, or until I get some spare time to write my own implementation (not in the short term).