Allow PHP 8.4 in laminas-cache 3.x

[driehle]

Q	A
Documentation	yes/no
Bugfix	yes/no
BC Break	yes/no
New Feature	yes/no
RFC	yes/no
QA	yes/no

Description

[driehle]

@froschdesign

This is a follow-up on doctrine/DoctrineORMModule#767, on how PHP 8.4 support could be added to laminas-cache 3.x series. Technically it works, there are, however, some issues:

Due to the architecture of laminas-cache, there is a dependency on the root project. Therefore, Composer needs to inflect the version of the root package and, obviously, fails to do so. The initial error in CI was:

    - laminas/laminas-cache-storage-adapter-filesystem 2.4.1 requires laminas/laminas-cache ^3.10.0 
      -> found laminas/laminas-cache[4.2.x-dev] but it does not match the constraint. 
           See https://getcomposer.org/dep-on-root for details and assistance.

So it seems to inflect 4.2.x-dev, though 3.13.x-dev is what the value should be. First of all, there was typo in the pre-install.sh script, where COMPOSER_ROOT_VERISON was set. However, I think this script does not have any effect at all, at least fixing the typo doesn't change anything. I think this makes sense, since variables exported in Bash are lost when the script exits. So when the actuall Composer call is made, the variable will not be present anymore.

For now, I have set the version in composer.json, which is a bit hacky and ugly. A clean solution would probably be to integrate the code from the pre-install.sh script somwhere in the laminas-ci-matrix-action repository, so that COMPOSER_ROOT_VERSION can actually be set based on the target branch of the MR when Composer is called.

With the version pinned, most CI checks work. The docs seem to be failed, but I'd call this unrelated. The Psalm baseline probably needs to be updated, which I haven't done yet and the backward compatibility check, I have no idea what this is about. 🤷

[driehle]

I tried setting COMPOSER_ROOT_VERSION as @boesing suggested in laminas/laminas-continuous-integration-action#35, i.e. the GitHub way by writing to $GITHUB_ENV. However, this doesn't work and after thinking about it, in indeed does make sense that it does not work: Both composer install and the following phpunit call are executed in the same step, as there is only one CI step, which is the laminas/laminas-continuous-integration-action handling all the stuff in one single step. And according to GitHub docs the GITHUB_ENV is only for passing variables between different steps.

Therefore, I am surprised how the code in https://github.com/laminas/laminas-cache-storage-adapter-blackhole/blob/fe7bb4045fae6a71f8179744829aab6ddf47521e/.laminas-ci/composer-root-version.sh was supposed to work. In the same way, I am surprised how the code in this repository, using export COMPOSER_ROOT_VERSION, should ever have worked. Variables set in bash scripts are lost, once the script exits. This would only be possible, if the script is sourced, but that is not happening in https://github.com/laminas/laminas-continuous-integration-action/blob/1.41.x/entrypoint.sh#L176.