Installing Composer dependencies

[TangibleMark]

Hi Eliot,

We've been moving our projects over to Github from Bitbucket, and so I've been using the new Github Actions pipeline quite a bit. One major Issue I seem to be having with it, is that I can't find an easy way to generate a autoload.php file, and it doesn't seem to download the dependencies of my packages. For example this one line:
https://github.com/TangibleInc/tangible-searchsync/blob/main/composer.json#L28

Was able to install the Algolia library my project relied on. When I translate this to tangible.config.js:

{
      git:    'git@github.com:algolia/algoliasearch-client-php.git',
      dest:   'vendor/algolia/algoliasearch-client-php',
      branch: '4.6.4'
},

The library will be included, but then because there is no longer an autoload.php file, it will no longer be accessible to my project. I added a step to my pipeline to generate the autoload.php file, so now my project found it, only to discover that the dependencies of this library are not installed.

Any help on this matter would be much appreciated.

[eliot-akira]

Hi Mark, thanks for the issue description and context.

an easy way to generate a autoload.php file..and download the dependencies of my packages

It's true, this is an unsolved question. The Roller tool is designed to be JavaScript only, it doesn't require PHP or run Composer. That will have to be handled optionally in the build pipeline.

Looks like this step in the GitHub Actions workflow is meant to perform the two tasks mentioned above: install Composer dependencies and generate the autoload file. Is it maybe missing the install command?

      # Install external deps and generate autoload.php + a fresh lock
      - name: Install PHP dependencies (Composer)
        uses: php-actions/composer@v6
        with:
          php_version: '8.2'
+         command: install
          args: --no-dev --prefer-dist --no-interaction --no-progress --optimize-autoloader

https://github.com/TangibleInc/tangible-searchsync/blob/8b616bf555471f5cf1632546d597a632a0cfb360/.github/workflows/release.yml#L38-L43

Possibly Roller can provide a config option to make this process more convenient, like running certain commands when PHP is available on the system.

[TangibleMark]

Hi Eliot.

Nico had suggested that I use the roller to install internal PHP dependencies (Tangible framework, tangible updater etc) and add a composer step to install my external dependencies. So I added that composer step you've listed above. I haven't been able to get it working, but if/when I manage it I'll be sure to let you and the team know. I try that install command you suggested.

[TangibleMark]

I was able to get a pipeline that seems to build much like the old one here: https://github.com/TangibleInc/tangible-searchsync/blob/main/.github/workflows/release.yml

Feel free to close this issue if installing these dependencies will be outside the scope of the roller.

I think in general it would be nice if the framework did ship with a pipeline that can build your plugin out of the box like the old one did. It looks like Nico also shared a commit of how to make composer install the dependencies, so as long as that information gets a spread across the company it should be inconsequential.

[eliot-akira]

Much appreciated, thanks for sharing the updated pipeline script that installs Composer dependencies. And for mentioning Nicolas' commit https://github.com/TangibleInc/lifter-elements/commit/de3cb98563178e4fa4b8cca94f601c433da42157 which I hadn't noticed.

# Install external deps and generate autoload.php + a fresh lock
- name: Install PHP dependencies (Composer)
  uses: php-actions/composer@v6
  with:
    php_version: '8.2'
    command: install
    args: --no-dev --prefer-dist --no-interaction --no-progress --optimize-autoloader

OK, comparing this line by line, it's the same as the snippet I suggested earlier. That's good to know it works.

For search-sync, I see it takes a different approach by installing PHP and Composer directly instead of the GitHub Action php-actions/composer. That's true, the latter installs and runs everything in a container. The setup looks similar with Git, SSH, workspace directory, Composer cache.

# CHANGE: Install PHP and Composer on the runner (not in a Dockerized action)
# This avoids Git "dubious ownership" inside a container and lets us control git config directly.

I see, there was some issue that this approach is meant to solve. About ownership, typically a Docker command is run with options to map the host user ID to the root user in the container, so any mounted folders and files are accessed with the same ownership and permissions. But it sounds like it wasn't working in this case.

Anyway, as long as it works - this way is more efficient without a container, and it's nice to see the exact commands for the setup, compared to it being hidden behind the abstraction of a third-party script.

---

it would be nice if the framework did ship with a pipeline that can build your plugin out of the box

I agree, it's a common need that's better solved with a standardized workflow. This Roller tool is meant more for frontend assets (JS/TS/Sass/CSS), so I think the Composer setup belongs in the Pipeline module and in the documentation site.

• https://github.com/TangibleInc/pipeline
• https://github.com/TangibleInc/docs

And it would be nice if we had an example plugin with Composer dependencies, to demonstrate the entire setup.

So I'll create issues in corresponding repos as a reminder, and integrate this knowledge in the common workflow.

---

One thing to note about Composer dependencies in WordPress plugins is that there's a risk of namespace or version conflict when two plugins include multiple instances of the same dependency, particularly popular modules like symphony/* and guzzlehttp.

Tangible modules like Framework and Updater have a module loader that handles this, by having a registry of available versions and loading a single instance of the newest version. However most Composer modules are not designed this way.

Ideally such public dependencies are vendored in with a unique namespace using a tool like php-scoper.

• PHP Scoper: How to Avoid Namespace Issues in your Composer Dependencies

I haven't had the chance to actually set it up, but if/when someone figures it out, I'd like to document the steps in the docs site and integrate it as part of the common plugin setup and build pipeline.

[eliot-akira]

OK, I've created these issues, and will close this one.

• Install PHP and Composer dependencies pipeline#5
• Document build pipeline setup to install PHP and Composer dependencies docs#1

[eliot-akira]

Git "dubious ownership" inside a container

I see, I found the error in the action logs.

• try adding install command to the compooser action #29

Searching for the message on GitHub, it's been reported here:

• The repository at "/app" does not have the correct ownership and git refuses to use it dunglas/symfony-docker#744
• “Detected dubious ownership” issue when using php-actions/composer@v6 php-actions/composer#120

..which leads to the root cause in Composer.

• composer update failure composer/composer#12221

The issue might be with the fact that the user used for git clone is not the user with whom you execute the composer command.

---

Here's the log for the build step that threw the error.

Run php-actions/composer@v6
  with:
    php_version: 8.2
    command: config
    args: --global --add safe.directory /app
    version: latest
    interaction: no
    dev: yes
    progress: no
    quiet: no
Run set -e
  set -e
  bash <(curl -s https://raw.githubusercontent.com/php-actions/php-build/v2.2.0/php-build.bash) composer
  /home/runner/work/_actions/php-actions/composer/v6/composer-action.bash
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    ACTION_VERSION: latest
    ACTION_PHP_VERSION: 8.2
    ACTION_PHP_EXTENSIONS: 
    ACTION_TOKEN: ***
    ACTION_COMMAND: config
    ACTION_ONLY_ARGS: 
    ACTION_INTERACTION: no
    ACTION_DEV: yes
    ACTION_PROGRESS: no
    ACTION_QUIET: no
    ACTION_ARGS: --global --add safe.directory /app
    ACTION_SSH_KEY: 
    ACTION_SSH_KEY_PUB: 
    ACTION_SSH_DOMAIN: 
    ACTION_SSH_PORT: 
    ACTION_WORKING_DIR: 
    ACTION_MEMORY_LIMIT: 
    ACTION_CONTAINER_WORKDIR: 
Building PHP 8.2 with extensions:  ...
Error: The "--add" option does not exist.
The repository at "/app" does not have the correct ownership and git refuses to use it:

fatal: detected dubious ownership in repository at '/app'
To add an exception for this directory, call:

	git config --global --add safe.directory /app


                                      
  The "--add" option does not exist.  
                                      

config [-g|--global] [-e|--editor] [-a|--auth] [--unset] [-l|--list] [-f|--file FILE] [--absolute] [-j|--json] [-m|--merge] [--append] [--source] [--] [<setting-key> [<setting-value>...]]

Error: Process completed with exit code 1.

Looks like this particular error is about the --add option in the arguments to composer. I think the solution here is to run it as git config command.

# Fix: mark /app safe inside the Composer container
\- name: Composer git safe.directory
  uses: php-actions/composer@v6
  with:
    php_version: '8.2'
-   command: config
-   args: --global --add safe.directory /app
+ run: git config --global --add safe.directory /app

---

Edit: I see a similar solution is already there in the newest workflow.

      # CHANGE: Mark the workspace as safe for Git, since Composer will run on the host now.
      - name: Git safe.directory
        run: |
          git config --global --add safe.directory "$GITHUB_WORKSPACE"

The difference is that this runs git config on the host, whereas my suggestion would run it in the container where Composer is installed by the GitHub Action php-actions/composer.

Well, the end result is the same. I'll try to include relevant info in the docs.

[eliot-akira]

I think the fix for Composer in a container can be run as part of the same step. I'll see if this works.

# Install external deps, generate autoload and lock file
# Configure workspace as safe for Git to solve: https://github.com/composer/composer/issues/12221
- name: Install PHP dependencies (Composer)
  uses: php-actions/composer@v6
  with:
    php_version: '8.2'
  run: |
    git config --global --add safe.directory /app
    composer install --no-dev --prefer-dist --no-interaction --no-progress --optimize-autoloader

This looks better kept as part of each plugin's build workflow, an additional step as needed. The Pipeline module is used for pre/post release scripts, which would have to run the above GitHub Action step in a child process.

• Document optional step to install Composer dependencies TangibleInc/pipeline@4ccc1c7
• Update docs for Pipeline module TangibleInc/docs@1de13d8

---

About the need for unique namespace, I made a note of it.

• Document how to solve unique namespace in external Composer dependencies docs#2

[eliot-akira]

a pipeline that can build your plugin out of the box

True, that would be the best. The build setup is a work in progress, and I hope eventually the incidental complexity can be reduced and hidden behind a simpler interface.

While searching for a way to let the Pipeline pre-release script run a GitHub Action, I learned there's a pre-installed command-line utility called gh (GitHub CLI) which can run workflows (gh workflow run).

So my thinking now is to add common workflow steps to the Pipeline module, then pre/post-release scripts can run them dynamically based on project setup. For example if composer.json exists and has a require property, run the workflow to install and run Composer.

Ideally a plugin would need just a minimal workflow file to install and run the pipeline, and the latter would take care of the rest. The GitHub Action steps, shell commands, and inevitable workarounds for various situations would be solved and consolidated in the build pipeline.