fix: allow matrix testing without EOL versions

[rhoerr]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/mage-os/github-actions/blob/main/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

What is the current behavior?

Installation and integration tests fail for 2.3.7 to 2.4.1 because they require Composer 1, which no longer works. Packagist ended Composer 1 support as of September 01 2025.

Fixes: https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18158077121

What is the new behavior?

No longer attempts to build versions below Magento 2.4.2.

Does this PR introduce a breaking change?

• Yes
• No

Will no longer support Magento versions below 2.4.2 (but they're already inherently broken).

Other information

[rhoerr]

@damienwebdev Is this an appropriate change, given the circumstances?

Installation and integration tests fail for 2.3.7 to 2.4.1 because they require Composer 1, which no longer works. Packagist ended Composer 1 support as of September 01 2025.

Fixes: https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18158077121

[fballiano]

I proposed to remove the old beta releases before, so I completely agree on this PR.

[rhoerr]

Latest mirror build has integrity checks mostly fixed, except for these affecting 2.3.7-2.4.1, and preexisting constraint edge cases for a couple releases in 2.4.4 and 2.4.5. https://github.com/mage-os/generate-mirror-repo-js/actions/runs/18217417183

[damienwebdev]

I kinda feel like we need a different kind for this use-case. Perhaps useable.

Most people (from my original repo and what I use internally) use currently-supported (the default)

all (what the generate-mirror-repo-js uses) is a special use-case for people who need to enumerate the whole list of all magento releases. When @danslo wrote that workflow, that made sense. However, given that software is not stagnant, what he may instead of have meant to say was all-useable or useable or all-modern.

Instead of modifying the raw data, what we should instead do is modify get-matrix-for-kind to handle this new kind (Also adding docs as necessary)

The only complexity I can think of is how "useable" is determined. I'd probably add a flag to the raw json data on each version indicating whether its currently useable or not. We could instead do it based upon some unique computation of "is it composer 1", "is it RabbitMQ 1+", etc, but that sounds painful and esoteric. I'd rather just decide based upon world events (the deprecation of composer 1 for example) when something becomes unusable.

[rhoerr]

Thanks Damien. I'll see what that means in terms of real world changes here.

I like the useable kind of flag idea. Simple enough concept.

I think this isn't a blocker for the next release round in ~10 days, so we can take some time to get it right. We can and have chosen to ignore certain integrity test errors at times for expedience. This doesn't break processes, just throws unavoidable warnings right now.

[fballiano]

generating a mirror release is becoming slower and slower the more versions we have, in my opinion removing stuff that can't be used anyway is priority to make the processes a bit faster allowing us to work better

[rhoerr]

Be that as it may, preserving mirror integrity seems better than temporarily shaving a few minutes off build times. Dropping build times will require fundamental changes to how we actually build historical releases, in a sense that we'd probably best not rebuild them at all. But that's a very different undertaking I'm not sure any of us have time for now.

For now, I added a usable kind per Damien's suggestion, and restored those old versions. Tests pass green. This will require a separate change to the mirror workflow to switch the matrix type and skip those old versions in testing.

I opted to do the evaluation in code (whether composer < 2), rather than adding a usable flag per version. This way we just need to update the rules there if any such issues happen in the future.

@damienwebdev , ready for review again when convenient. Should be fully backwards compatible.

[damienwebdev]

This looks fantastic @rhoerr ! The only comments I have are that the action.yml and the README are missing the new kind.

[rhoerr]

@damienwebdev Thanks -- updated readme and action.yml.

[damienwebdev]

Lgtm