Can't Specify Composer Minor/Patch Versions

[timnolte]

If I try to specific Composer 2.2 or 2.2.9 for example my GitHub Actions fail with

/usr/local/bin/composer: line 2: syntax error: unexpected newline

I'm only able to specify version "2", otherwise it fails.

[g105b]

I've just checked and can confirm that this is a limitation in the current implementation.

Thank you for submitting this issue.

Notes for a fix:

The composer phar that is downloaded uses the https://getcomposer.org/download/latest-{version}/composer.phar template. If a specific version is passed (for instance, if a period is present in the version string), the template should be changed to https://getcomposer.org/download/{version}/composer.phar.

The bash script will need to check for a presence of the dot. If no dot is supplied, e.g. 2, latest-2 should continue to be used.

[timnolte]

@g105b was this actually fixed by this PR, but hasn't been made available to GitHub Actions yet? #77

[timnolte]

@g105b or maybe that is where the versioning was introduced but the actual point releases aren't working as expected?

[timnolte]

@g105b I think I understand now how that Composer versioning was designed. If I want Composer 2.2 I need to use 2.2.x as the version number currently.

[timnolte]

@g105b sorry for all of the comments. So I tried with '2.2.x' and it's still breaking.

[g105b]

No problem. I'll pick this up when I'm home. Spam me all you like :)

[g105b]

Hey @timnolte , please see https://github.com/php-actions/example-composer/runs/6141219754?check_suite_focus=true and the action config https://github.com/php-actions/example-composer/actions/runs/2212864881/workflow

With this change I'm able to choose between version 2 (getting latest v2 release), 2.2 (getting latest v2.2 patch) and 2.3.1 (getting specific version release).

Please can you test this in your workflow and let me know how you get on?

[timnolte]

@g105b sorry, I had to move on from this and just stick with specifying version 2 for now. I'll try to find time to revisit and test this week yet.

[timnolte]

@g105b FYI, I looked at your run tests and the test for "Use latest 2.3" is actually wrong. You can see from the output it installed version 2.2.12.

[g105b]

@timnolte thanks for pointing that out, it's actually a typo! If you look in the variable I sent in, the requested version is 2.2, but the title of the test "use latest 2.3" is typed incorrectly. I'll change it to avoid confusion.

[timnolte]

@g105b sorry for the delay. I've tested out the changes and I can successfully get version 2.2. One thing that I am however stuck on is the fact that this GitHub Action doesn't actually seem to install Composer(or the specified PHP version for that matter), so I'm still needing to use the shivammathur/setup-php GitHub Action to setup a matching local environment so that I can run Composer scripts for linting & static analysis to ensure they are running under the same environment. Fortunately I'm able to lever age environment variables to manage the versions in a consistent way.

[g105b]

Your follow up question outlines the big difference between php-actions and shivammathur's implementations: php-actions are intentionally containerised, meaning there are no side effects on the Github Action runner after it has been run.

I wonder if this could be solved by having a new php-actions repo for running specific scripts in the same containerised environment? I like that idea - would like to hear your feedback.

[timnolte]

Yeah, so for some additional context to my use case. I need to run a matrix of WordPress, WooCommerce, and PHP versions. This is all done via Composer require calls that change the lock file and then we perform a final install, along with running unit tests. In other workflows we run linting and static analysis. Running all of that in containerized environments would actually be preferred but isn't possible right now with this Action. Ideally there would be a run parameter that we could either pass an array of commands to run or a piped string of commands.