Bug or configuration error? (PHP Version used)

[internalsystemerror]

Hi, I'm investigating implementing renovate for Laminas framework (https://getlaminas.org/).

The configuration I'm testing is here: laminas/.github#19.

There is an issue when updating the lockfile and the problem is one mentioned in a previous discussion. The highest available PHP version is always used. For example a constraint of ~7.4 || ~8.0.0 || ~8.1.0 will use an image with version 8.1.1.

The checks run using each of those versions and since packages are installed that require PHP 8, our checks for PHP 7.4 fail and we would be unable to get any lock file updates. I would suggest that the lowest minor PHP version is used as PHP 7 code will for the vast majority of cases, work on PHP 8. However the reverse is not true.

That's not a rule that applies to everyone though, so a configuration option here might be preferable, highest vs lowest language version.

An example of this issue occurring can be found here: https://github.com/internalsystemerror/laminas-servicemanager/pull/4.

One possible workaround that I've not tried is to manually specify the PHP version in the config section of each composer.json file. There are a lot of repositories and this would then have other implications so I would rather avoid this at all costs.

[viceice]

Add constraints.php="~7.4" to renovate config.

https://docs.renovatebot.com/configuration-options/#constraints

[internalsystemerror]

The docs?

[rarkins]

For "constraints"

[internalsystemerror]

To which PR are you referring? If you mean the renovate configuration for laminas, I'm unaware of where this is incorrect? If you mean the one for yourselves that's not involving constraints?

[rarkins]

It's related to this:

The link you provided does not list php

Although I just realized that it's supported managers, not languages, and composer is listed there. So you can disregard this suggestion

[internalsystemerror]

Ohhhh, I get you now sorry. I have tested a constraint of php and that appears to work as expected though.

[rarkins]

I'm not a regular PHP/Composer user, so I can't tell from your example immediately what's wrong. Do you mean that Renovate is implicitly "upgrading" the PHP version within that changed lockfile? e.g. it could be compared to going from npm@6 to npm@7 where the lock file format changed?

And if so, is there some obvious field or other way in which Renovate could automatically detect the version of PHP in use for the existing lockfile, in order to reuse the same?

[internalsystemerror]

The option that @viceice suggested would possible fix this allowing us to specify the version we wish to use for generating the lockfile. However this differs from repository to repository depending on the packages we need and the minimum PHP version they support, along with which PHP versions still receive security updates.

So what we would like to do is to say use the lowest-minor version from that PHP range so that it can be applied across all 3 orgs.

[internalsystemerror]

One last thing just regarding whether its possible to autodetect the PHP version from the lockfile. Unfortunately not. There is a platform.php key inside composer.lock, however this is often just a copy and paste of any php requirement set in the require section.

[rarkins]

It sounds like you'd need a new feature where Renovate would be instructed to select the minimum matching version instead of maximum.

[rarkins]

BTW Renovate itself may select versions to update composer.json to which you don't like, too.

[internalsystemerror]

But those would fail CI and open a PR giving us an indication as to why it failed. Our concern is primarily for the lock file maintenance. I will test adding a constraint and see how that changes things.

[viceice]

Looks like #13657 will improve this a lot