Closed ryantfowler closed 4 years ago
Thanks for reporting. To be honest : I totally forgot about that whilst creating this package. I'll have to play around with the setup of this package to make it possible here as well.
@veewee You're welcome :). My apologies for communicating a bug back to you :(. I really appreciate the work that you've done with this project. It has been very valuable to me in my work. I hope that this feedback is constructive. If I am able to, I'll also try to figure out a solution, and if I'm successful, I'll open a PR for your review.
Thank you
Hello @ryantfowler,
I've fixed this issue by directly initializing the phar scripts from the shell script. It seems to work from my POV. Can you verify if #2 fixes the issue for you?
(It will be shipped soon in 0.17.1)
@veewee thanks for doing this. I'll take a look and get back to you. If I'm interested in this phar being ran inside a docker container, which I would have configured in my git hooks, wouldn't the same problem I reported be repeated, since this code attempts to execute a php interpreter vs running something like exec('docker'
call?
Your docker container has to contain php with phar enabled. In that case the git hook runs something like docker ... grumphp
.
This will open up your docker container and run the grumphp command inside that container.
But since this package is PHP, a valid php runtime is required inside the container.
That makes sense. My intentions were to attempt to use this shim in a similar manner that I use the pure phpro/grumphp
package, which would be like this: https://github.com/phpro/grumphp/pull/618#issuecomment-483001498 . The link I shared allows for me to run git operations on my host machine or within my docker container, and in both cases, grumphp will execute beautifully. At the moment, it doesn't seem like this is possible with the shim. Maybe the link I shared helps to clarify what I meant when I opened this issue?
I don't get why this wouldn't be possible with the shim package?
The git hook should still contain the configured EXEC_GRUMPHP_COMMAND
.
The git hook behaves in a similar way as the original package. The only difference is that the code is in a phar file.
(The original package contains a grumphp executable which is PHP as well, this package contains a grumphp executable that is a wrapper around the phar)
Can you elaborate on what is failing on your end?
I think I understand now. I think part of my error was how I had configured the git hooks with this shim. Let me give it a shot again, and I'll get back to you. Following your code changes, I haven't tested it out, so it's just been theoretical. I'll get back to you. Thanks
First, I think it's great that there's a Composer plugin for Grumphp. Kudos. Next, I have found that the
vendor/bin/grumphp
file starts off with$(which php)
which effectively nutralizes any benefits that may be present in using the pure Composer packagephpro/grumphp
which utilizes git_hook_variables, and therefore allows for configuring Grumphp for a native php stack/Vagrant/Docker.This Composer plugin doesn't, from my experiments and what I can tell, support being ran on Vagrant/Docker.
My sample
grumphp.yml
file:My resulting
.git/hooks/pre-commit
:Sample output:
The above git commands were ran from my host machine, and didn't prevent the git operations, but also didn't work as I would expect (executing via the php executable within the specified docker container).
When I use
phpro/grumphp
instead ofphpro/grumphp-shim
, use the samegrumphp.yml
file, and end up with the same.git/hooks/pre-commit
shown above, and commit file changes from my host machine, the following is output:This Composer plugin does solve dealing with "dependency hell," which is great. I just think that in order to be more available to more realistic and modern development environments, that the
git_hook_variables
( at the least ) should be incorporated here.