Switch Travis CI environment to Trusty - PHP 5.2 & 5.3 no longer available Sept 2017

[netweb]

Travis CI have announced they are going to switch to Trusty as the default distro come July 18th 2017

​https://blog.travis-ci.com/2017-07-11-trusty-as-default-linux-is-coming

Incoming patch will allow us to continue having PHP 5.2 and 5.3 Travis CI jobs until September 2017

---

The current availability of PHP 5.2 and 5.3 in the Travis CI build environment is the following:

1. dist: precise with sudo: false
2. dist: trusty with sudo: false
3. dist: precise with sudo: false
4. dist: precise with sudo: required

WordPress' current Travis CI config uses option 1 above
Travis CI will override this configuration with option 2 come July 18th 2017
Workaround this issue for PHP 5.2 & 5.3 until September 2017 using option 3 for the PHP 5.2 and 5.3 Travis CI jobs
Come September 2017 Travis CI will overwrite option 3 above with option 4

I've created the following Travis CI issue on the subject: ​https://github.com/travis-ci/travis-ci/issues/8072

[netweb]

Patch 41292.diff​ will see us through until approx September 2017

Test PR and Travis CI jobs (in progress):

• ​https://github.com/ntwb/wordpress/pull/3
• ​https://travis-ci.org/ntwb/wordpress/builds/252673342
• ​https://travis-ci.org/ntwb/wordpress/builds/252673173

[rmccue]

The post does note:

We have no immediate plans to discontinue support for jobs that specify sudo: required and dist: precise, although we do not plan to update the images for these jobs any more.

Seems like we could continue using that for now.

Apart from that, we could simply use a ​Docker container with PHP 5.2. There's a bunch of 5.2 containers available that we could choose from, or we could build and roll our own.

[netweb]

Replying to rmccue:

The post does note:

We have no immediate plans to discontinue support for jobs that specify sudo: required and dist: precise, although we do not plan to update the images for these jobs any more.

Seems like we could continue using that for now.

PHP 5.2 and PHP 5.3 are *not* available on the sudo: required infrastructure

Apart from that, we could simply use a ​Docker container with PHP 5.2. There's a bunch of 5.2 containers available that we could choose from, or we could build and roll our own.

Yup, I think that time has come +1

[netweb]

Ticket updated and patch refreshed in 41292.2.diff​ to include PHP 5.3

Current Travis CI Build: ​https://travis-ci.org/ntwb/wordpress/builds/252678568

[netweb]

Replying to netweb:

Ticket updated and patch refreshed in 41292.2.diff​ to include PHP 5.3

Current Travis CI Build: ​https://travis-ci.org/ntwb/wordpress/builds/252678568

Travis CI build has passed, all green, ready for commit please

[jnylen0]

As just discussed in Slack, this will need backport to all the branches or builds will start failing. Milestoning in 4.8.1 because we are already in that release cycle. I'll commit to trunk in a few minutes.

[jnylen0]

In 41072:

Build: Switch PHP 5.2 and 5.3 to Travis' Ubuntu precise image

Starting today, Travis will begin switching the default image to trusty, which does not support PHP 5.2 or 5.3.

This is not a full fix, because Travis will be dropping precise support entirely in September (​https://github.com/travis-ci/travis-ci/issues/8072). However, it buys us some time until then.

Props netweb.
Fixes #41292 for trunk.

[jnylen0]

Reopening for backports, most urgently the 4.8 branch.

[jnylen0]

After fixing the immediate issue here, a potentially lighter-weight alternative to Docker would be to use ​phpbrew to build PHP 5.2, then use ​Travis' built-in caching mechanism to avoid doing this on every build. We'll probably want to make use of that caching either way.

If we try to build our own PHP 5.2, here are a couple of configurations/patches that we will proably need to apply:

• undefined reference to symbol blahblahblah openssl: ​https://github.com/phpbrew/phpbrew/issues/111#issuecomment-173811458
• ext/dom/node.c: error: dereferencing pointer to incomplete type: ​https://github.com/phpbrew/phpbrew/issues/249#issuecomment-58273934 / ​https://github.com/phpbrew/phpbrew/wiki/TroubleShooting#error-dereferencing-pointer-to-incomplete-type

[netweb]

Replying to jnylen0:

After fixing the immediate issue here, a potentially lighter-weight alternative to Docker would be to use ​phpbrew to build PHP 5.2, then use ​Travis' built-in caching mechanism to avoid doing this on every build. We'll probably want to make use of that caching either way.

If we try to build our own PHP 5.2, here are a couple of configurations/patches that we will proably need to apply:

• undefined reference to symbol blahblahblah openssl: ​https://github.com/phpbrew/phpbrew/issues/111#issuecomment-173811458
• ext/dom/node.c: error: dereferencing pointer to incomplete type: ​https://github.com/phpbrew/phpbrew/issues/249#issuecomment-58273934 / ​https://github.com/phpbrew/phpbrew/wiki/TroubleShooting#error-dereferencing-pointer-to-incomplete-type

I've not looked at any of the above and per the Travis CI issue it wasn't just the compiling PHP binaries:

​https://github.com/travis-ci/travis-ci/issues/2963#issuecomment-127238259

I should note here that support for PHP 5.2 and 5.3 on Trusty is not just about compiling the binary. From what I recall, PHPUnit can no longer be installed via PEAR, which I believe is the only means by which it can be installed on PHP 5.2 and 5.3 (​https://github.com/sebastianbergmann/phpunit/wiki/End-of-Life-for-PEAR-Installation-Method).

[johnbillion]

In 41073:

Build: Switch PHP 5.2 and 5.3 to Travis' Ubuntu precise image

Starting today, Travis will begin switching the default image to trusty, which does not support PHP 5.2 or 5.3.

This is not a full fix, because Travis will be dropping precise support entirely in September (​https://github.com/travis-ci/travis-ci/issues/8072). However, it buys us some time until then.

See #41292

Merges [41072] to the 4.8 branch.

[johnbillion]

In 41074:

Build: Switch PHP 5.2 and 5.3 to Travis' Ubuntu precise image

Starting today, Travis will begin switching the default image to trusty, which does not support PHP 5.2 or 5.3.

This is not a full fix, because Travis will be dropping precise support entirely in September (​https://github.com/travis-ci/travis-ci/issues/8072). However, it buys us some time until then.

See #41292

Merges [41072] to the 4.7 branch.

[johnbillion]

In 41075:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image.

See #41292

[jnylen0]

Replying to netweb:

I've not looked at any of the above and per the Travis CI issue it wasn't just the compiling PHP binaries:

From what I recall, PHPUnit can no longer be installed via PEAR, which I believe is the only means by which it can be installed on PHP 5.2 and 5.3

Probably worth discussing on that GitHub issue too, but this isn't very difficult to fix either: just download a .phar archive of the desired version to /some/bin/dir/phpunit and mark it executable.

[johnbillion]

In 41076:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.5 branch.

See #41292

[johnbillion]

In 41078:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.4 branch.

See #41292

[johnbillion]

In 41079:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.3 branch.

See #41292

[johnbillion]

In 41080:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.2 branch.

See #41292

[johnbillion]

In 41081:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.1 branch.

See #41292

[johnbillion]

In 41082:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 4.0 branch.

See #41292

[johnbillion]

In 41083:

Build: Switch PHP 5.2 to Travis' Ubuntu precise image for the 3.9 branch.

See #41292

[johnbillion]

This is all good back to 4.0, but 3.9 is erroring: ​https://travis-ci.org/WordPress/wordpress-develop/builds/254893856

[netweb]

Replying to jnylen0:

In 41072:

Build: Switch PHP 5.2 and 5.3 to Travis' Ubuntu precise image

Starting today, Travis will begin switching the default image to trusty, which does not support PHP 5.2 or 5.3.

This is not a full fix, because Travis will be dropping precise support entirely in September (​https://github.com/travis-ci/travis-ci/issues/8072). However, it buys us some time until then.

Props netweb.
Fixes #41292 for trunk.

Linking to the upstream issue in regard to PHP Nightly (7.2.0-dev) unexpected Travis CI build failures:
​https://github.com/travis-ci/travis-ci/issues/8114

[jnylen0]

Getting this out of the 4.8.1 milestone now that this is resolved in trunk and 4.8.

[netweb]

Replying to netweb:

Linking to the upstream issue in regard to PHP Nightly (7.2.0-dev) unexpected Travis CI build failures:
​https://github.com/travis-ci/travis-ci/issues/8114

This issue has now been resolved upstream by Travis CI, issue was due to "unreliable MySQL availability"

Restarted nightly job now fails as expected: ​https://travis-ci.org/WordPress/wordpress-develop/jobs/254762313

[notnownikki]

I'm taking a look at this problem for the Gutenberg project, so I'll share my progress here and hopefully it'll be easily applicable.

[notnownikki]

Some progress here. I have a script that will run on a stock trusty install and provide php 5.2/5.3

Unfortunately, there is no phpunit-3.6 release to be found on ​https://phar.phpunit.de/, so for php-5.2 tests we'll have to install the phpunit-3.6 branch from ​https://github.com/sebastianbergmann/phpunit/tree/3.6

Once I have a full environment with phpunit working with php-5.2 and php-5.3, I'll test the travis caching, and cache all the built binaries and phpunit installation.

[notnownikki]

...and having read further, install from git is going to be the only way for both versions!

Ok, someone remind me that I volunteered to do this... :)

[netweb]

Thanks @notnownikki, have you opened an issue on Gutenberg yet or do you have any links to issues or repos you're using, I'd be interested to follow along any progress on this...

[notnownikki]

Replying to netweb:

Thanks @notnownikki, have you opened an issue on Gutenberg yet or do you have any links to issues or repos you're using, I'd be interested to follow along any progress on this...

The Gutenberg issue is ​https://github.com/WordPress/gutenberg/issues/2048

I have a script working that installs PHP5.3, PHP5.2, PHPUnit 4.8, and PHPUnit 3.6.

It uses phpbrew to install and switch between the versions of PHP, and you just need to alias phpunit to either phpunit-4.8 or phpunit-3.6 to make sure the right one runs.

Everything lives in the home directory, so the installation of phpbrew, phpunit, and php versions can be cached so we're not building php every time we run a test.

I'm looking at integrating the script into the Gutenberg travis configuration now, and once that's done it should be easily reusable.

[notnownikki]

Fix is in gutenberg now and seems to be working well. Initial build takes a while (~25 mins) but once it's in the travis cache, there's no noticable slowdown.

​https://github.com/WordPress/gutenberg/commit/3c3427472fadd4696347956b3b3e409bd21d606d

[miyauchi]

I developed Docker Images which are installed PHP 5.2 - 7.1 and PHPUnit.
I am believing that we can run phpunit with PHP 5.2 by using these Docker images on Travis CI.
(I already tried to run phpunit for WordPress core on my local environment.)

I will submit example to GitHub, so if you have an interesting please review.

​https://hub.docker.com/r/miya0001/phpenv/tags/
​https://github.com/miya0001/docker-phpenv

I will very happy if we release wordpress/phpenv image on the dockerhub. :)

[netweb]

Thanks @miyauchi a few questions if I may:

• Why create Docker images for PHP 54 - 7.1? Do you see a benefit in using custom images over the available PHP 5.4 - 7.x offered by Travis CI?

• Have you tried implementing any Travis CI caching?

• I see you're using phpenv whereas @notnownikki used phpbrew, are there benefits of one over the other?

That's about it from me right now, @notnownikki would you be able to take a look at this seeing as you authored the Gutenberg implementation please ?

[notnownikki]

I've only just become aware of phpenv, and it looks like it includes more patches by default, although in Gutenberg we've added the patches and build config needed, so it's not an issue, especially as we only build once and then use the travis cache.

When we test with older php versions, do we need these loaded as apache modules, or are we just running the cli? For Gutenberg, we only run the cli, installing the apache module is trickier, and possibly phpenv would be better for that, as it includes apache installation support, although we would need root access to do that.

[miyauchi]

Hi @netweb

Thanks for reply.

Why create Docker images for PHP 54 - 7.1? Do you see a benefit in using custom images over the available PHP 5.4 - 7.x offered by Travis CI?

I guess it will be able to be .travis.yml simple and we can run phpunit on the same settings.
Creating image is reasonable because those images are built automatically on Travis CI.

Have you tried implementing any Travis CI caching?

Not yet. :)
I guess Travis CI can't cache docker image.

I see you're using phpenv whereas @notnownikki used phpbrew, are there benefits of one over the other?

phpbrew say:

To get older versions (less than 5.4)
Please note that we don't guarantee that you can build the php versions that are not supported by offical successfully,
please don't fire any issue about the older versions, these issues won't be fixed."

​https://github.com/phpbrew/phpbrew#basic-usage

I create a sample GitHub repository which runs phpunit with Docker + PHP5.2 +.
I haven't run qunit yet for now.

​https://travis-ci.org/miya0001/wordpress-develop
​https://github.com/WordPress/wordpress-develop/compare/master...miya0001:docker-based-ci

I will try to add tests with multiple versions of MySQL with docker.

Thanks :)

[desrosj]

This will be solved when #47767 is backported in #48301.

Going to close this out as fixed since some work was done here. If anyone feels strongly about using a different resolution, free to change it.