* Fix opensearch versions based on wardenenv container support
* opensearchproject/opensearch:2.19.1
* Disable opensearch security
* spawn separate opensearch service when needed
* fix opensearch flags; fix PackageMatrixVersion type and test
* Try mysql:8.4 over mariadb:11.4
* updated dist/index.js
* Allow trigger creation during integration tests
* chore: add Magento Open Source 2.4.7-p2 and Mage-OS Distribution 1.0.4 to the version matrix
* chore: add Magento 2.4.4-p10, 2.4.5-p9, 2.4.6-p7 to the version matrix
fix: pass correct repo url for nightly
The amendMatrixForNext function uses the repository argument to
determine the version constraint for the returned matrix for kind
nightly.
Previously, the upstream-mirror repo url was passed as an argument, but
the nightly builds use a different repo url.
This resulted in failed builds, because the version string 'next' could
not be parsed by composer.
Example:
https://github.com/mage-os/generate-mirror-repo-js/actions/runs/6370219504/job/17291152703
With this change, the nightly kind will always return the @alpha
version constraint, that is, stability constraint.
There currently is no way to distinguish between different nightly
repos, but since both work the same way, this is fine (for now).
* refactor: allow version matrixes by projects
* feat: add initial version-matrix for mage-os
* feat: add project as optional input to action
* docs: document new input
* refactor: tighten types a bit
* chore: apply change requests from code review
Previously, we didn't take into account a release date, which meant
that @vinai could not add MageOS or Magento releases before the actual
day of release.
With this, we can now add the releases to supported verisons before
a release comes out, allowing us to make a kind that allows testing
MageOS and Magento Mirror releases more quickly.
Previously, @danslo reported that he tried to use `custom_versions` without
setting the kind. This isn't the correct behavior.
I've added a validator to alert him of this.
Previously, I maintained supported versions by revising a file of versions. This was monotonous, like time.
Now, these are just based upon the documented EoL dates of the versions published by Magento.
Github released Ubuntu 22.04 as a runner for many actions: https://github.com/actions/runner-images/issues/5490.
As a result, we started experiencing intermittent failures as the underlying runner's support varied for older versions of Magento.