We are currently rebuilding our php execution container architecture and build process, and am getting close enough to where we can deploy these new containers.

This is going to allow us to *rapidly* make changes to the container builds to try and hunt down environment based issues with the testbots.

Currently, the container labels and their versions are as follows:

  • PHP 5.3 - version 5.3.29
  • PHP 5.4 - version 5.4.39
  • PHP 5.5 - version 5.5.23
  • PHP 5.6 - version 5.6.7
  • PHP 7 - version chasing 7.0snapshot, which is the 7.0.X branch of php7.

We're going to be transitioning from those five environments to a total of ten php environments, which will consiste of the following:

Most recent stable releases of EOL php versions:

  • PHP 5.3.29 - version 5.3.29
  • PHP 5.4.45 - version 5.4.45
  • PHP 5.5.38 - version 5.5.38

Minimum supported version of php on drupal 8:

  • PHP 5.5.9 - version 5.5.9

Most recent supported stable minor releases of PHP

We will continue to update the containers as newer point releases happen

  • PHP 5.6 - version 5.6.29 currently
  • PHP 7.0 - version 7.0.14 currently
  • PHP 7.1 - version 7.1.0 currently

Development snapshots of PHP

We will have a container for each development snapshot of php to ensure that we know in advance of incoming upstream changes.

  • PHP 5.6.X - follows 5.6 git branch
  • PHP 7.0.X - follows 7.0 git branch
  • PHP 7.1.X - follows 7.1 git branch

Transition Steps

10 php environments will make many of the UI/UX elements unwieldy, especially if we start adding additional database types, multiplied by the number of branches available. We still need to come up with a design to rework how that is managed. In the meantime, the plan is to replace the existing four labels with the following containers:

  • PHP 5.3 - version 5.3.29
  • PHP 5.4 - version 5.4.39
  • PHP 5.5 - version 5.5.38
  • PHP 5.6 - version 5.6.29 (will stay up to date)

The final question then, is what to do with php 7? I suggest we keep the php7 label for now (so as to not have to do a bunch of work renaming things) and add one more environment for php 7.1 like so:

  • PHP 7 - version 7.0.X stable: 7.0.14 currently
  • PHP 7.1 - version 7.1.X stable 7.1.0 currently

The second step will then be to come up with a UI that allows for configuring and setting up all of these varied environments so we can use all of the php containers.

Please weigh in and +1 or provide feedback. I'd like to get these newer containers into production asap so we can start troubleshooting the random failures we've been seeing much more rapidly.

Comments

Mixologic created an issue. See original summary.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I think we're offering real value to the PHP community by running against the tip of PHP... and it helps us know stuff early too. So for D8 I think we should have the following containers to start with.

  • PHP 5.5 - version 5.5.38
  • PHP 5.6 - version 5.6.29 (will stay up to date)
  • PHP 7 - version 7.0.X stable: 7.0.14 currently (will stay up to date)
  • PHP 7.1 - version 7.1.X stable 7.1.0 currently (will stay up to date)
  • PHP 7.1.X - follows 7.0 git branch

Getting 5.5.9 and the UI for more PHP versions can happen in it's own time.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

I think we're offering real value to the PHP community by running against the tip of PHP

I totally agree - just not sure what tip we should use, now that theres essentially two of them. 7.0 or 7.1? We're currently on 7.0 mostly due to history.

We can probably get away with adding one of the dev snapshots for now provided we dont expand that to include additional databases (just stick with mysql 5.5)

catch’s picture

catch
he/him
Primary language English
commented

Generally this looks great, on things that look outstanding:

5.5.9 also isn't a priority (putting it mildly) for me for testing compared to anything else.

I'd go for 7.1 for the HEAD PHP version if we have to pick one.

One remaining question for me is what we do when 7.2 starts development, we should be testing with the betas at least - do we switch HEAD to that at the time, or add a new environment entirely, or keep HEAD on the stable branch and add a new environment tracking beta/rc/stables?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Issue summary: View changes

(Fixed one typo.)

What I'm missing is a plan for future PHP versions. When the PHP 7.2 (N+1) branch opens, do we follow that? I assume we would. But what happens with PHP 7.0 and 7.1 (N-1 and N)? Do we keep only 7.1 (N) and drop 7.0 (N-1)? Or do we keep 7.0 indefinitely, and we just keep adding all the new minor PHP 7 versions?

Agreeing on how to handle that is a bit more work now, but means we won't have to revisit this for years to come.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I think we should be testing against every stable minor version of PHP we support - so PHP 5.5, PHP 5.6, PHP 7.0 and PHP 7.1. We should also by testing against the HEAD of PHP. The moment there is a stable release of 7.2 we add that and keep on testing on the HEAD of PHP.

mpdonadio’s picture

mpdonadio
he/him
Primary language English
Location Philadelphia/PA/USA (UTC-5)
commented

I think #6 is a good idea instead of N-1. This will better support the major distros. For example, even though 7.1 is out, it looks like Ubuntu 16LTS is sticking with 7.0 (at least for now).

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

#6++, that's exactly what I hoped for :)

catch’s picture

catch
he/him
Primary language English
commented

Yep our PHP support dropping policy is not very well defined, but de-facto it's whatever we can get away with in a major release, and 'when the last Linux distro LTS version supporting the release goes EOL" - this means PHP 5.5 until April 2019 unless we change that, and if Ubuntu 16.04 LTS stays on PHP 7.0 it'll be similarly long there too - unless we change what we do ourselves a bit.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: MIgrating to new php container versions » Migrating to new php container versions
Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

So an update:
I have the following containers built and passing core tests, and plan on

Supported releases

5.5.38 https://dispatcher.drupalci.org/job/drupalci_test_containers/726/
5.6 (PHP 5.6.29) https://dispatcher.drupalci.org/job/drupalci_test_containers/721/
7.0 (7.0.14) https://dispatcher.drupalci.org/job/drupalci_test_containers/727/

Development Branch Snapshots

5.6.X https://dispatcher.drupalci.org/job/drupalci_test_containers/718/
7.0.X https://dispatcher.drupalci.org/job/drupalci_test_containers/728/

PHP 7.1

The following two php7.1 containers are built, but have fails, but Im pretty sure those are drupal & php 7.1 fails and not container issues:

7.1 (7.1.0) https://dispatcher.drupalci.org/job/drupalci_test_containers/729/
7.1.X https://dispatcher.drupalci.org/job/drupalci_test_containers/730/

I would like to start transitioning these in,

swapping 5.5/5.6/7 for the supported releases, and, for now, adding the 7.1, and 7.1.x branches as new envs.

Once we have a better UI/UX defined, we'll introduce the 5.6.X, and 7.0.X, in addition to the 5.5.9 container Im getting going too. (we may be adding more databases, thus the explosion of potential environments can be both costly and hard to manage, so we want to be careful about how that gets delivered)

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

New containers are deployed, and I went ahead and added most of the available options: (the UX isnt perfect, but thats the enemy of the good anyhow)

So, now we have:

  • php 5.5 has been upgraded from php 5.5.23 - 5.5.38
  • php 5.6 has been upgraded from 5.6.7 to 5.6.29, and Both pgsql and sqlite db envs were added.
  • php 7 now points at a stable version of php 7, specifically 7.0.14
  • php 7.0.x branch now exists which is what our former php 7 tests were chasing, (mysql only)
  • php 7.1 branch now exists which is the first stable (7.1.0) (mysql only)
  • php 7.1.x branch is also available which chases pretty close to php head. (mysql only)

@wim leers: Additionally, all php7 versions come with apcu enabled now, which they did not have before.

Still TODO:

  • There exists a 5.6.x branch container, but I did not enable it yet,
  • I started work on a 5.5.9 container that uses normal ubuntu apt-get tools on trusty to create an environment that mocks our "lowest common denominator" - but its not done yet
  • Still need to make the 5.3 and 5.4 containers for d7. Note, I will *not* be making 5.2 containers, despite our weakish commitment to supporting 5.2 on d7 with certain patches in certain environments - unless Im told otherwise.
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

@wim leers: Additionally, all php7 versions come with apcu enabled now, which they did not have before.

Great! That sounds very helpful. Means we can catch APCu-related bugs on testbot, also in PHP 7.

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

I've updated the ongoing PHP container support policy for DrupalCI here: https://www.drupal.org/drupalorg/docs/drupal-ci/drupalci-php-support-policy

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented
Status: Needs review » Fixed

Havent heard any feedback on the policy, so I'll assume its good enough and call it fixed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.