Open sprankhub opened 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.
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.
I got tired of fighting this. https://github.com/graycoreio/github-actions-magento2 has a very clear and concise way to accomplish this now.
@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.
@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.
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!
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:
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.:If this was possible, we could simply define a matrix, replace
ce_version
andphp_version
with the matrix value and we are done.