Action erroring out on with incorrect invalid `composer.json` report
jrfnl opened this issue Β· comments
Description
Okay, so this is a "fun" one π. If I make a simple --no-update
change ahead of running the composer-install
action, it will error out saying the composer.json
file is invalid, while in actual fact the composer.json
file is perfectly valid, but the (committed) lock
file is out of date (which may be completely intentional).
Making a --no-update
change ahead of running the composer-install
action is a common way to ensure the caching done via composer-install
is used optimally, while still being able to make select changes depending on the PHP version the workflow is being run on.
Steps to reproduce
- On a repo with a committed
composer.lock
file - Run a
composer .... --no-update
command or other Composer command which won't runupdate
, likecomposer config --unset platform.php
- Try to run a
composer update
via the action and see it fail. - Run
composer validate --strict
: it will indicate thecomposer.json
is valid, but thelock
file is out of date../composer.json is valid but your composer.lock has some errors # Lock file errors - The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update` or `composer update <package name>`.
Example code to reproduce the issue: https://github.com/jrfnl/composer-install-action-bug
Action run showing the bug: https://github.com/jrfnl/composer-install-action-bug/actions/runs/1620893221
Expected behavior
That the composer-install
action doesn't error out on the lock
file being out of date as this may be wholly intentional, especially if a (selective) composer update
is being run via the composer-install
action.
Environment details
- version of this package: 2.0.2
- PHP version: not relevant
- OS: not relevant
FYI: I've got a fix lined up for this, as well as the test for it, I just can't get the test to be recognized by expect
.
Unfortunately, I'm out of luck with the (otherwise very informative) CONTRIBUTING
doc, as it presumes dev on a *nix based machine, while I'm on Windows, so autoexpect
isn't available (the last Windows release for coreutils
is 5.3.0).
How would you like me to proceed ?
FYI: I've got a fix lined up for this, as well as the test for it, I just can't get the test to be recognized by expect.
Go ahead and push your fix and open the PR for it. I can help with the expect tests.