extdn / github-actions-m2

137 stars 46 forks source link

Improve Configuration With Multiple PHP / Magento Versions #24

Open sprankhub opened 3 years ago

sprankhub commented 3 years ago

Due to the current structure, testing multiple Magento versions on multiple PHP versions is currently not that nice to configure. We only found the following way to do it:

steps:
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.3.5-p2 (PHP 7.3)
    uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.3.5-p2'
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.3.6-p1 (PHP 7.3)
    uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.3.6-p1'
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.4.1-p1 (PHP 7.3)
    uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.4.1-p1'
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.3)
    uses: extdn/github-actions-m2/magento-integration-tests/7.3@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.4.2'
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.4.1-p1 (PHP 7.4)
    uses: extdn/github-actions-m2/magento-integration-tests/7.4@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.4.1-p1'
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.4)
    uses: extdn/github-actions-m2/magento-integration-tests/7.4@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.4.2'

It contains a lot of duplications, which is not that nice. I would prefer to use the matrix feature of GitHub Actions. However, it is currently not possible to use a matrix value inside the uses section of the step configuration (see e.g. https://github.community/t/using-strategy-matrix-values-in-the-specification-of-actions-to-be-used-in-a-workflow/16706). Hence, I think the PHP version should not be referenced in the action name. It should be defined as an option. E.g.:

steps:
  - uses: actions/checkout@v2
  - name: M2 Integration Tests with Magento 2 Version 2.4.2 (PHP 7.4)
    uses: extdn/github-actions-m2/magento-integration-tests@master
    with:
      module_name: Vendor_Module
      composer_name: vendor/module
      ce_version: '2.3.5-p2'
      php_version: '7.4'

If this was possible, we could simply define a matrix, replace ce_version and php_version with the matrix value and we are done.

fooman commented 3 years ago

@sprankhub indeed this is not yet ideal. The issue I encountered when trying to pass in the php version is that we are also not able to use this input parameter value in the action here. So then we end up with needing to do this at runtime which adds execution time.

I was thinking to go further down the route of having even more images that have the Magento install already done (and maybe keep the current way as an option as it does catch 1 type of issue with the sequencing of modules and db installs).

But maybe we end up having various different options so that every one can choose what works best for them.

kolaente commented 3 years ago

I think this is a good way to solve this: https://github.com/MAD-I-T/magento-actions/blob/master/entrypoint.sh#L6

Ideally this could be combined with a base image to provide a php option for all actions in this repo.

damienwebdev commented 2 years ago

I got tired of fighting this. https://github.com/graycoreio/github-actions-magento2 has a very clear and concise way to accomplish this now.

jissereitsma commented 2 years ago

@damienwebdev I'm not sure which fight you got tired off. But indeed if it is the structure of the current ExtDN actions that would need to be refactored into something else, then I feel I need to point out that the ExtDN actions are open for contributions, definitely by ExtDN members. The work you have put into a personal version instead is in the spirit of open source and I find nothing wrong with that. There can be multiple open source projects with the same goal - let users decide which is better. But by posting here, I got the feeling that you would have liked that your fix / change was part of the ExtDN repo instead, but never suggested here - a fight was over before it got started.

damienwebdev commented 2 years ago

@jissereitsma

I'm really looking to leverage my actions as a trial for an API of actions that could replace ExtDN Actions (a v2 of sorts).

To be clear, I wholly intend to donate my actions repo back to this repo.

My concern and the reason for not contributing directly is that my changes are fairly breaking. I changed APIs that felt uncomfortable to me and I took a different approach by publishing a mix of workflows and actions.

Consider the docker images that you use here as an example, that layer alone chiefly prevented the usage of matrixes and changing it around would break the API.

In addition, I didn't see a clear way to layer in my idea around "supported versions".

Ultimately, the diff count to get from here to there seemed gratuitous and time-inefficient.

"Fight" was likely a strong choice of words, which I wrote out of frustration (which I'm sorry about), but I was chiefly fighting the API, not the people of this project.

jissereitsma commented 2 years ago

To be clear, I wholly intend to donate my actions repo back to this repo.

Nice. Nuff said :)

My concern and the reason for not contributing directly is that my changes are fairly breaking.

This is actually also my struggle into trying to make improvements. I'm not sure who is using what in what kind of way. A v2 sounds more like a plan!