When ignore-cache is true, composer update runs instead of composer install

[flagbrad]

Hi @ramsey , thanks so much for this action. It enabled my organization to accomplish a major new web project's release.

Steps to reproduce:

• Create a workflow that uses ramsey/composer-install
• Set ignore-cache: true when invoking it. All other options default, which should cause composer install and honoring of composer.lock.
• Run the workflow.
• Observe in the resulting log that composer_install.sh receives no composer.lock file
• Observe through the workflow log or filesystem that composer update was actually invoked.

Expected behavior: composer install is invoked when this action is run with default options.

Screenshots

Preliminary analysis

If the cache is ignored, then composer and composer.lock paths are not determined because of this conditional. This subsequently results in composer_install.sh receiving no composer.lock argument, which causes it to run composer update instead of composer install because of this line.

I might not be understanding some complexity here, but to me it seems that determining composer paths should always happen, irrespective of cache settings. If so, this is a one line fix... just remove the if conditional on the composer paths step in action.yml . Glad to submit a PR for this, but I wanted to submit the issue first since I'm new to using this action and lack confidence in my full understanding!

[ramsey]

This does look like a bug that was introduced when I converted this to a composite action. Great catch! Feel free to open a PR.