Error "changing permissions" with vendored_phpunit_path

[alexpts]

My CI config:

strategy:
  matrix:
    php-verwsions: [ 8.1, 8.2 ]

steps:
  - uses: actions/checkout@v3
  - uses: php-actions/composer@v6

  - name: phpunit tests ${{ matrix.php-versions }}
    uses: php-actions/phpunit@v3
    with:
      bootstrap: vendor/autoload.php
      configuration: test/phpunit.xml
      php_extensions: pcov
      php_version: ${{ matrix.php-versions }}
      vendored_phpunit_path: vendor/bin/phpunit

Logs: https://github.com/alexpts/php-simple-events/actions/runs/3845578313/jobs/6549883176

I want use phpunit version from my package.lock file. I try use vendored_phpunit_path with value vendor/bin/phpunit as path to phpunit framework. I have error chmod: changing permissions of '/home/runner/work/php-simple-events/php-simple-events/vendor/bin/phpunit': Operation not permitted

[georgique]

I can confirm this to be a problem.

[g105b]

Thank you for the error report. I'll look into this and replicate on https://github.com/php-actions/example-phpunit

[alexpts]

@g105b, Are there any successes?

[UndeMa01]

Got the same problem too :~(

[damienwebdev]

Same issue here.

https://github.com/php-actions/phpunit/blob/master/phpunit-action.bash#L26

In the event that you use the vendored path, I don't see a reason to chmod the file, perhaps a simple if not null check is sufficient but I leave to @g105b to determine the legitimacy of such a change.

[paul-m]

Are there any reasonable workarounds that still use the action? I'm using a wide matrix of PHP versions and need to run whichever version of PHPUnit gets installed in vendor to ensure compatibility.

[g105b]

@damienwebdev the reason the chmod is being used is so the container can execute phpunit after the phar download is moved to /usr/local/bin/phpunit. If we didn't add the executable bit, the phpunit command would fail.

That's my reasoning anyway, but I'm sure you're on to something with your thought. I will give this some more attention, I don't think the solution will be too difficult to find.

Edit:

Having said that, I've just checked the contents of my vendor/bin directory, and all the phar files are already set to have the executable bit, so maybe your idea of only setting if we need to will be all that's needed.

[g105b]

@paul-m, @alexpts, and others in this thread, please can you try using a test branch I've set up for this issue:

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      uses: php-actions/phpunit@chmod-permission

I've made a change so the chmod operation is only attempted if the phar is not executable. As long as your phar is executable (it should be already), there is no need for chmod to operate.

I hope this solves your issues.

[paul-m]

Hey, thanks for this.

I’m seeing these results:

https://github.com/paul-m/csv-response/actions/runs/4306092463/jobs/7509443986

If you click through the PHPUnit step you'll see that it was unable to run phpunit because of path shenannigans. It could also be user error or a bad path in vendored_phpunit_path, but I'm not sure.

[alexpts]

@g105b It didn't help me.

I tried the version "php-actions/phpunit@chmod-permission". Here is my configuration and result - https://github.com/alexpts/php-simple-router/actions/runs/4926071360/workflow

[g105b]

Calling the attention of @alexpts @paul-m @UndeMa01 @georgique @damienwebdev

Firstly, please accept my apologies for taking so long to get around to this. This year has been really busy with work that pays the bills, and I've had to neglect the open source projects for a while.

I believe I have a fix for this - stemming all the way back to the php-build process, which is a Docker container that creates a minimal installation of PHP to your Github Actions' specifications, the entire build process is performed under the runner user.

I would appreciate it if you could test this for me with the following changes to the versions of the Actions:

    steps:
      - uses: actions/checkout@v3
      - uses: php-actions/composer@run-as-current-user

      - name: PHPUnit Tests
        uses: php-actions/phpunit@composer-version--user

Note the php-actions/composer Action is running as version run-as-current-user, which specifies the temporary php-build version, and php-actions/phpunit is running as version composer-version--user.

Thanks in advance!

Edit: I've tested this myself using my own workflows, and it seems good. I'll do a lot more testing and if all goes well I'll release these changes. I will like to make the release on 6th October. Your feedback is really appreciated.

[shanept]

I confirm I am also having this issue. I am looking into it now and hoping to have a fix (at least for what I'm getting). It seems the chmod-permissions fix is the start of it, however on my system it then leads to the following issue:

I now notice the following:

1. At the bottom of phpunit-action.bash, the vendored phpunit path is mounted as a volume in docker to /usr/local/bin/phpunit. Thus, if my vendored phpunit path is 'vendor/bin/phpunit', that is the file that is then mounted to /usr/local/bin/phpunit.
2. If I then open vendor/bin/phpunit, right at the bottom I see it is attempting to point to "vendor/bin/phpunit/../phpunit/phpunit/phpunit", which is where our error is coming from.

When we typically run vendor/bin/phpunit, it is basically just a shortcut to run vendor/phpunit/phpunit/phpunit. I attempted to amend my vendored_phpunit_path to point there instead, unfortunately it expects certain variables as set in vendor/bin/phpunit. Thus the best approach is to put the full path to the binary in the phpunit command string, within phpunit-action.bash.

I will be creating a pull request with this implemented shortly. For those who wish to test/use this, please use shanept/phpunit@vendored_phpunit_path_fix as the action.