Opened 7 years ago
Closed 5 years ago
#41292 closed defect (bug) (fixed)
Switch Travis CI environment to Trusty - PHP 5.2 & 5.3 no longer available Sept 2017
Reported by: | netweb | Owned by: | jnylen0 |
---|---|---|---|
Milestone: | 4.8.1 | Priority: | high |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
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:
-
dist: precise
withsudo: false
-
dist: trusty
withsudo: false
-
dist: precise
withsudo: false
-
dist: precise
withsudo: 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
Attachments (2)
Change History (43)
#2
follow-up:
↓ 3
@
7 years ago
The post does note:
We have no immediate plans to discontinue support for jobs that specify
sudo: required
anddist: 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.
#3
in reply to:
↑ 2
@
7 years ago
- Keywords needs-refresh added
Replying to rmccue:
The post does note:
We have no immediate plans to discontinue support for jobs that specify
sudo: required
anddist: 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
#4
@
7 years ago
- Description modified (diff)
- Summary changed from Switch Travis CI environment to Trusty - PHP 5.2 to be no longer available Sept 2017 to Switch Travis CI environment to Trusty - PHP 5.2 & 5.3 no longer available Sept 2017
#5
follow-up:
↓ 6
@
7 years ago
- Keywords needs-refresh removed
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
#6
in reply to:
↑ 5
@
7 years ago
- Keywords commit added
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
This ticket was mentioned in Slack in #core by netweb. View the logs.
7 years ago
#9
@
7 years ago
- Description modified (diff)
- Milestone changed from 4.9 to 4.8.1
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.
#10
follow-up:
↓ 27
@
7 years ago
- Owner set to jnylen0
- Resolution set to fixed
- Status changed from new to closed
In 41072:
#11
@
7 years ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
Reopening for backports, most urgently the 4.8 branch.
This ticket was mentioned in Slack in #core-php by jnylen. View the logs.
7 years ago
#13
follow-up:
↓ 14
@
7 years ago
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-173811458ext/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
#14
in reply to:
↑ 13
;
follow-up:
↓ 18
@
7 years ago
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-173811458ext/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).
#18
in reply to:
↑ 14
@
7 years ago
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.
#26
@
7 years ago
- Keywords has-patch commit removed
This is all good back to 4.0, but 3.9 is erroring: https://travis-ci.org/WordPress/wordpress-develop/builds/254893856
#27
in reply to:
↑ 10
;
follow-up:
↓ 29
@
7 years ago
Replying to jnylen0:
In 41072:
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
#28
@
7 years ago
- Keywords fixed-major removed
- Milestone changed from 4.8.1 to Future Release
Getting this out of the 4.8.1 milestone now that this is resolved in trunk
and 4.8
.
#29
in reply to:
↑ 27
@
7 years ago
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
#30
@
7 years ago
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.
#31
@
7 years ago
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.
#32
follow-up:
↓ 33
@
7 years ago
...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... :)
#33
in reply to:
↑ 32
;
follow-up:
↓ 34
@
7 years ago
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...
#34
in reply to:
↑ 33
@
7 years ago
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.
This ticket was mentioned in Slack in #core by netweb. View the logs.
7 years ago
#36
@
7 years ago
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
#37
@
7 years ago
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. :)
#38
@
7 years ago
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 usedphpbrew
, 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 ?
#39
@
7 years ago
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.
#40
@
7 years ago
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 :)
Patch 41292.diff will see us through until approx September 2017
Test PR and Travis CI jobs (in progress):