search

php-actions / composer

Use the Composer CLI in your Github Actions.
175 stars 54 forks source link

Can't Specify Composer Minor/Patch Versions #79

Closed timnolte closed 2 years ago

timnolte commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@g105b was this actually fixed by this PR, but hasn't been made available to GitHub Actions yet? https://github.com/php-actions/composer/pull/77

timnolte commented 2 years ago

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

timnolte commented 2 years ago

@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 commented 2 years ago

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

g105b commented 2 years ago

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

g105b commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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.

g105b commented 2 years ago

Cool. OK well this is certainly something I'll add to my to-do list! php-actions/php-run will be super useful. Thanks for helping form the idea.