No errors output when composer.json is invalid about composer-install

[jrfnl]

Just a heads-up: I ran into the 'usr/local/bin/composer' failed with exit code 1 error myself today.
In my case, the cause was a silly typo in the composer.json.

Might it be an idea to run composer validate --strict before running the composer install and to exit with the output of the validate command if that fails ? That would probably catch most issues and should show a more helpful error message.

[ramsey]

Comment from @Kocal on #58 (comment):

Hum, I'm trying to use the new release since #93 has been merged, but I have error The process '/usr/local/bin/composer' failed with exit code 1. That's weird since checks from #93 were all green... 😓

@ramsey do you have an idea how can I debug this? Since it's working on the action's CI but not on other CI, I don't know where and how to start 😞
Thanks!

[ramsey]

Good idea, @jrfnl!

[ramsey]

The latest version (2.0.1) includes composer.json validation and emits an error in the GitHub Action runner, if it encounters a validation error.

[ramsey]

To clarify, I don't think these two errors are related, but we do need some better error messaging when composer fails like this, to make it easier to debug.

[Kocal]

I started working on this and I found something interesting.

Using the following step on two repositories (my fork Kocal#2 and another private repo which needs working-directory)

-   uses: ramsey/composer-install@v1
    with:
        dependency-versions: locked
        composer-options: --unknown-option

I'm having different outputs:

• the fork, I have all the infos I need (https://github.com/Kocal/composer-install/runs/2050396017?check_suite_focus=true#step:4:12):
  
• the other private repo, I have literally nothing:
  

I don't know why do we have different outputs... Maybe because we run the action on the action's repo?

[alexander-schranz]

The validate command will fail in none libraries like a symfony based project e.g.:

composer create-project symfony/skeleton
cd skeleton
composer validate --strict

Will fail with:

name : The property name is required
description : The property description is required

Also in our cases linting is an own task in our CIs, so I would not add this as part of the installation.

[jrfnl]

@alexander-schranz Just composer validate (without the strict) should get round that and should still provide more usable error messages, so I think it's still a viable solution.