Composer is not running as a current user (it runs as root)

[gleniat]

I set up the linux user runner on my self-hosted linux machine. I installed the service with sudo ./svc.sh install runner and started it with ./svc.sh start. The installed runner runs as runner user, but the php-actions/composer creates vendor directory owned by root.

jobs:
  deploy:
    runs-on: self-hosted
    steps:
      - name: Whoami
        run: whoami

      - name: Checkout project
        uses: actions/checkout@v2
      
      - name: Install composer dependencies
        uses: php-actions/composer@v6
        with:
          php_version: "8.0"

whoami prints runner as expected.

after Install composer dependencies step, the listing of files look like this:

$ ls -l /home/runner/runners/my-project-runner/_work/my-project/my-project/
total 656
...
drwxr-xr-x  6 runner runner   4096 Sep 12 16:13 public
drwxr-xr-x  6 runner runner   4096 Sep 12 16:13 resources
drwxr-xr-x  2 runner runner   4096 Sep 12 16:13 routes
-rw-r--r--  1 runner runner    563 Sep 12 16:13 server.php
drwxr-xr-x  5 runner runner   4096 Sep 12 16:13 storage
drwxr-xr-x  4 runner runner   4096 Sep 12 16:13 tests
drwxr-xr-x 47 root   root     4096 Sep 12 16:15 vendor
-rw-r--r--  1 runner runner    538 Sep 12 16:13 webpack.mix.js

How can I run php-actions/composer@v6 as a current user so vendor folder is created as runner:runner?

[g105b]

Hi @gleniat,

The instance of Composer runs in a Docker container, with no users created within it. It might take a bit of thinking to get the inside of the container running with the same user as the file owners on the outside.

What problem are you facing due to the files being owned by root?

[SomeBdyElse]

Hi @gleniat , Hi @g105b !

I had the same issue. In my case a product specific composer plugin created var/tmp/… folders after composer install. The folders were created but belonged to root. Later, a phpunit test was unable to create new files within that folder and failed.

To ensure that the folders created by composer install will be writable during the unit tests, I switched to:

    - name: Setup PHP
      uses: shivammathur/setup-php@v2
      with:
        php-version: 7.4
        tools: composer
        extensions: pdo, sqlite3

    - name: composer install
      run: composer install -n

    - name: phpunit
      run: .Build/bin/phpunit -c … Tests/Unit

[Andalu30]

A first approach to this problem may be allowing the user to set the user with which they want to run the docker container. You can set the --user arg when executing a docker run command. We're currently using this in a few places in our pipelines. This potentially solves the problem of #31 if the docker container is run with the same user.

I'm not familiar with this codebase or even with GithubActions development but it looks like an user env var could be added to the docker run command pretty easily. If I have a bit of downtime I can test a few things and report or even PR that change.

Edit: my fork appears to work correctly. It's not automatic user discovery but it at least allows to set the user for docker which solves my problem.

      - uses: Andalu30/composer@test
        name: Composer install using forked GH action
        with:
          docker_user: 1001

[g105b]

@Andalu30 this looks really promising! We can test on https://github.com/php-actions/example-composer if you like? Would you be able to create a test workflow there, or if you can share the one you're testing on, I can add this test to the example-composer repo.

[nicko170]

This is an issue when using pestphp/pest with the coverage option, as by default they store in the vendor directory.