Provide separate images per PHP version

[dkarlovi]

The project currently provides only PHP 7.2:

phpqa/Dockerfile

Line 1 in 8e0d36a

FROM php:7.2-cli

phpqa/Dockerfile-alpine

Line 1 in 8e0d36a

FROM php:7.2-alpine

This was also mentioned as a problem here:
https://twitter.com/mwop/status/1012417504319279107

It might make sense to provide an image for each officially supported PHP Docker image currently available. If you're running on Travis, you'd just pass the version through your env vars, wouldn't even need to request PHP.

[jakzal]

Since initially I created this image to run static analysis on code bases I reviewed for clients, the PHP version didn't matter. Static analysis doesn't actually execute the code. I made a conscious decision to only support the latest PHP version. It's just less maintenance.

With most of tools php version won't matter. It might make a difference for some recently added testing tools though (like phpunit).

I'm not saying no, but I'd like to see if it's really worth supporting more PHP versions.

It would help if I knew how people actually use these images, as I expect the original use case has expanded :)

[dkarlovi]

Static analysis tools also take the version into account since they extract information out of (current) built-in classes to determine if the usage is correct.

This is how I use it, mostly.

More examples:
https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/blob/master/Makefile
https://github.com/rollerworks/search/blob/master/Makefile

The idea is to use the image locally on the dev workstation and on the CI too, which allows to have the CI build be really fast and not bothered by failed installation of random dev utilities you don't directly care about in your build, you just want to use them. Basically, hardening the process and speeding it up at the same time.

But, this approach currently doesn't allow running the suite against different versions since in the end, you end up running it within this image anyway.

[jakzal]

Static analysis tools also take the version into account since they extract information out of (current) built-in classes to determine if the usage is correct.

Could you give me an example?

[dkarlovi]

Can't find the exact example right now (even though I'm 95% I saw one referenced), but you can see the effect here for example: phpredis/phpredis#1374

The reflection reads the information available in the runtime and uses that as a basis for all work that follows. If the information is wrong, either because of the wrong version (changed API or wrong signature, like here), the conclusions will be wrong too.

[madnight]

@dkarlovi is right

We either need support for multiple php versions. I think that wouldn't be to hard with an automated script. Or at least, lets not use php 7.2 because some tools do not run correctly under php 7.2 yet, but on lower versions.

[jakzal]

some tools do not run correctly under php 7.2 yet

@madnight could you be more specific? From what I understand the mostly maintained tools actually drop legacy PHP versions quite quickly. For example, phpstan "only" supports php ^7.1. What do you suggest to do to install it with php 5.6 (which is still a supported docker image)?

[jakzal]

Please understand I'm trying to challenge you guys before we add more maintenance to this repo. I'm not against this idea, just trying to play devil's advocate here.

One idea I had is to extract the installer from this repository and provide it as a standalone tool. This repo would then only provide the latest php, but you could easily install any tools in your docker image or on the computer directly:

phpqa-installer install phpstan phan phpmetrics
phpqa-installer install --all

The above could be actually implemented regardless of what's our decision on this issue.
WDYT?

[madnight]

What do you suggest to do to install it with ..

Currently I would suggest 7.1, I think it has the best support.. On the long run I would suggest to always stay one version behind the newest php version*, that is to say give the devs some time to upgrade their code bases.

*or if there's no php version update for a long time, then just upgrade to the newest after some time

[dkarlovi]

One idea I had is to extract the installer from this repository and provide it as a standalone tool.

This does seem like a cool concept. We would need to expand the installer to allow for skipping incompatible tools. Or better, replace them with compatible versions (Psalm has a PHP 5.x compatible release, for example).

[jakzal]

@dkarlovi @madnight please have a look at #83. I decided to only support the currently officially supported PHP versions. I'll be removing support slowly as tools stop supporting them.

One thing left to do is to decide on the tagging system. I'd appreciate your input here.

To be backwards compatible, I think the current way of tagging should be kept for the latest supported version of PHP. Where do we append the PHP version to other images though?

Example:

• 1.12.1, 1.12, latest (debian, latest php)
• 1.12.1-alpine, 1.12-alpine, alpine (alpine, latest php)
• 1.12.1-php7.1, 1.12-php7.1, php7.1 (debian, php 7.1)
• 1.12.1-php7.1-alpine, 1.12-php7.1-alpine, php7.1-alpine (alpine, php 7.1)
• 1.12.1-php7.2, 1.12-php7.2, php7.2 (debian, php 7.2)
• 1.12.1-php7.2-alpine, 1.12-php7.2-alpine, php7.2-alpine (alpine, php 7.2)

[dkarlovi]

I like this. 💯

If I say latest, it should imply "Latest PHP, latest tools" (same with alpine), that works as-is for most uses.

If I'm using it in CI, I want to be specific about the PHP version (so, php7.1, php-7.2), but want the latest version of the tools).

If I want to use the older (or fixed) version of tools and PHP, I can also do that. LGTM. 👍

[madnight]

yup, such a version matrix would be great!

[jakzal]

Release made. Waiting for docker hub to build.

[dkarlovi]

It looks like each version is being built separately? https://hub.docker.com/r/jakzal/phpqa/builds/ I'd expect it to build it once and then tag with all the tags, so you'd have:

1. FROM php:7.1
2. FROM php:7.1-alpine
3. FROM php:7.2
4. FROM php:7.2-alpine