Renovate: Renovate using legacy PHP, incompatible with PHP 7.3+ code

Created on 9 Mar 2020 · 23Comments · Source: renovatebot/renovate

What Renovate type are you using?

self-hosted, GitLab

Describe the bug

I was recently investigating why our Renovate bot stopped working. It turned out it's using legacy PHP version 7.2.24 which makes it crash on parse error (with PHP 7.4 code).

Did you see anything helpful in debug logs?

  WARN: artifactErrors (repository=xxx/xxx branch=renovate/aws-aws-sdk-php-3.x)
       "artifactErrors": [
         {
           "lockFile": "xxx/composer.lock",
           "stderr": "Command failed: composer update aws/aws-sdk-php --with-dependencies --ignore-platform-reqs --no-ansi --no-interaction --no-scripts --no-autoloader\nDependency \"guzzlehttp/guzzle\" is also a root requirement, but is not explicitly whitelisted. Ignoring.\nDependency \"guzzlehttp/promises\" is also a root requirement, but is not explicitly whitelisted. Ignoring.\nDependency \"guzzlehttp/psr7\" is also a root requirement, but is not explicitly whitelisted. Ignoring.\nLoading composer repositories with package information\n\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b                                                      \b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\bUpdating dependencies (including require-dev)\nPackage operations: 207 installs, 0 updates, 0 removals\n  - Installing ocramius/package-versions (1.6.0): Downloading (100%)\nPHP Parse error:  syntax error, unexpected 'string' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in /xxx/vendor/ocramius/package-versions/src/PackageVersions/Installer.php on line 34\n"
         }
       ]
...
  INFO: Platform error - skipping (repository=xxx)

Additional context

I see Renovate is using --ignore-platform-reqs, this is extremely dangerous - if the project using Renovate was not ready for the latest PHP version this can easily introduce fatal errors. While it makes sense to overcome issue with missing PHP extensions it also opens a can of worms with unsupported PHP versions (otherwise specified under require.php)-

composer priority-2-important bug

Source

Majkl578

All 23 comments

[ ] PHP version in our Dockerfile can be updated
[ ] We could remove the ignoring of platform reqs for self-hosted, but would need to work out how to configure that

rarkins on 9 Mar 2020

👍1

We could remove the ignoring of platform reqs for self-hosted, but would need to work out how to configure that

I think this could be a bit tricky, given that people can use basically any arbitrary "ext-foo": "*" as dependency. Probably good for a separate issue for some research first.

Regarding PHP, I see you are using Ubuntu, I can highly recommend deb.sury.org as a source for the latest PHP versions even for LTS Ubuntu/Debian (the author is also a PHP maintainer in Debian project).
https://deb.sury.org/

Majkl578 on 9 Mar 2020

👍1

I am running into this issue as well for a Symfony 5 app. It eventually reaches a point where a certain package contains PHP 7.4 code and lockfile maintenance starts to fail:

Command failed: docker run --rm --name=renovate_composer --label=renovate_child -v "/mnt/renovate/gl/example":"/mnt/renovate/gl/example" -v "/tmp/renovate-cache":"/tmp/renovate-cache" -e COMPOSER_CACHE_DIR -w "/mnt/renovate/gl/example" renovate/composer bash -l -c "composer install --ignore-platform-reqs --no-ansi --no-interaction --no-scripts --no-autoloader"
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 109 installs, 0 updates, 0 removals
  - Installing symfony/flex (v1.6.2): Downloading (100%)
  - Installing ocramius/package-versions (1.7.0): Downloading (100%)
PHP Parse error:  syntax error, unexpected 'string' (T_STRING), expecting function (T_FUNCTION) or const (T_CONST) in /mnt/renovate/gl/example/vendor/ocramius/package-versions/src/PackageVersions/Installer.php on line 34

The code that triggers the error (PHP 7.4 typed properties):
https://github.com/Ocramius/PackageVersions/blob/651c372efc914aea8223e049f85afaf65e09ba23/src/PackageVersions/Installer.php#L34

msheakoski on 16 Mar 2020

Is it save to upgrade our php from 7.2 to 7.4? or do we need multiple versions?

Maybe we need multiple versions?

viceice on 16 Mar 2020

ok, multiple versions would be preferred, as some composer files explicit require a php version

viceice on 16 Mar 2020

It's a little challenging to support both multiple versions of PHP as well as Composer, i.e. then it becomes a "matrix". In Ruby we can get away with it because the Bundler install takes just a second or two, so then we dynamically switch Ruby base image version with "docker run" followed by dynamically installing the correct Bundler version.

rarkins on 16 Mar 2020

I think for now that installing the latest PHP in our Dockerfiles would be best

rarkins on 16 Mar 2020

👍1

ok, working on it

viceice on 16 Mar 2020

@viceice You can easily co-install multiple versions from the repository I mentioned above (it's safe, many people use it in production).

Majkl578 on 16 Mar 2020

@Majkl578 I know, we prefer to only have one version on our full docker image and have multiple images for the app, which uses the docker tools.

viceice on 16 Mar 2020

I’m interested to know how multiple versions of PHP can work? Can Composer itself auto-switch or do we need to run a command to change default PHP version before running Composer?

rarkins on 16 Mar 2020

No, one is always default as php (typically the highest one). Composer starts using #!/usr/bin/env php but you can explicitly run it with specific PHP version like php7.2 composer.phar install.

Majkl578 on 16 Mar 2020

I can imagine one can create a rather simple wrapper based on platform.php or require.php entry in composer.json (note that platform.php has precedence) to select which version will be used.

Majkl578 on 16 Mar 2020

🤔 so we have mustiple composer versions with multiple php versions?

Do we really need different php versions for composer install, or is it enough to have a supported version? Or does the php version depends on the current project too?

viceice on 16 Mar 2020

How many versions of PHP do we need to support? e.g. are all minor versions considered equivalent, so we can have latest 7.4.x, latest 7.3.x and that's it?

rarkins on 16 Mar 2020

I think the main issue is compatibility with newer PHP syntax in order for composer to install packages which run scripts without hitting any errors.

PHP 7.4 should be backwards-compatible with v7.2+, which is the current minimum supported version. https://www.php.net/supported-versions.php

msheakoski on 16 Mar 2020

So using 7.4 would be enough. Users have to update to a supported version, which should be compatible with 7.4?

viceice on 16 Mar 2020

So using 7.4 would be enough. Users have to update to a supported version, which should be compatible with 7.4?

I do not believe that users need to make any changes. If they are using any major framework or composer package, they are already required to use a minimum of PHP 7.2 anyway.

Even if they were not using 7.2, the backwards compatibility in most cases goes back to the PHP 5.x series which stopped receiving updates over a year ago.

msheakoski on 16 Mar 2020

And what about composer? Do we need multiple versions? Or is it enough to use the latest stable version?

viceice on 17 Mar 2020

Lets build all versions like we did with others - not much work once it’s automated

rarkins on 17 Mar 2020

👍1

Starting with 1.9.x, and 1.10.x

viceice on 17 Mar 2020

We could remove the ignoring of platform reqs for self-hosted, but would need to work out how to configure that

Did anything come of this?

I believe this would also semi solve https://github.com/renovatebot/renovate/issues/2355 as you could create a docker container with the minimum supported PHP version as a means of bypassing the lack of platform support.