Travis CI: timeouts on WP Codeception tests

[JDGrimes]

The builds just sit there and time out after ten minutes. See for example: https://travis-ci.org/WordPoints/wordpoints/jobs/320416415#L1114

I think this is related to the latest build updates on Travis's side.

[JDGrimes]

It looks like the page isn't loading fully:

Scenario:
* I am on page "/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks"
  [GET] http://127.0.0.1:8080/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42506 [200]: /wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42536 Invalid request (Unexpected EOF)
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42538 [200]: /wp-includes/css/dashicons.css?ver=5.0-alpha-42125-src
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42540 [200]: /wp-includes/css/buttons.css?ver=5.0-alpha-42125-src
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42542 [200]: /wp-admin/css/l10n.css?ver=5.0-alpha-42125-src
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42544 [200]: /wp-admin/css/login.css?ver=5.0-alpha-42125-src
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42548 [200]: /wp-admin/css/forms.css
[Sat Dec 23 16:27:14 2017] 127.0.0.1:42550 [200]: /wp-admin/css/l10n.css
[INFO  - 2017-12-23T16:31:35.879Z] SessionManagerReqHand - _cleanupWindowlessSessions - Asynchronous Sessions clean-up phase starting NOW
[INFO  - 2017-12-23T16:36:35.879Z] SessionManagerReqHand - _cleanupWindowlessSessions - Asynchronous Sessions clean-up phase starting NOW
[INFO  - 2017-12-23T16:41:35.879Z] SessionManagerReqHand - _cleanupWindowlessSessions - Asynchronous Sessions clean-up phase starting NOW
[INFO  - 2017-12-23T16:46:35.879Z] SessionManagerReqHand - _cleanupWindowlessSessions - Asynchronous Sessions clean-up phase starting NOW

Basically, the login screen apparently doesn't load fully, with the result that everything just freezes up or something.

[JDGrimes]

I ran this again with similar results:

Scenario:
* I am on page "/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks"
  [GET] http://127.0.0.1:8080/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40628 [200]: /wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_points_hooks
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40632 [200]: /wp-admin/css/forms.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40634 [200]: /wp-includes/css/dashicons.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40636 [200]: /wp-admin/css/l10n.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40638 [200]: /wp-admin/css/login.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40640 [200]: /wp-admin/css/forms.css
[Sat Dec 23 20:56:22 2017] 127.0.0.1:40642 [200]: /wp-admin/css/l10n.css
[INFO  - 2017-12-23T21:00:44.610Z] SessionManagerReqHand - _cleanupWindowlessSessions - Asynchronous Sessions clean-up phase starting NOW

The message about the invalid request isn't there, but the build still stalls at the same spot.

Here is what a successful request looks like:

Scenario:
* I am on page "/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_configure%26tab%3Dcomponents"
  [GET] http://127.0.0.1:8080/wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_configure%26tab%3Dcomponents
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39890 [200]: /wp-login.php?redirect_to=wp-admin%2Fadmin.php%3Fpage%3Dwordpoints_configure%26tab%3Dcomponents
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39918 [200]: /wp-includes/css/dashicons.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39926 [200]: /wp-includes/css/buttons.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39924 [200]: /wp-admin/css/forms.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39920 [200]: /wp-admin/css/l10n.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39922 [200]: /wp-admin/css/login.css?ver=5.0-alpha-42125-src
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39928 [200]: /wp-admin/css/forms.css
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39930 [200]: /wp-admin/css/l10n.css
[Sat Dec 23 20:56:07 2017] 127.0.0.1:39932 [200]: /wp-admin/images/wordpress-logo.svg?ver=20131107

You'll notice that they are basically the same, other than that on the stalled request there is no request for the WordPress logo that is displayed on the login page. I'm wondering if that is causing this.

In this most recent failure, the buttons.css file was also missing, but it wasn't from the previous failure posted above.

Let me see if I can reproduce any of this locally.

[JDGrimes]

I did find this SO question related to the Invalid Request message, but nothing there was really helpful. A suggestion that it was a bug fixed in PHP 7.2 didn't pan out, as the failure also occurs on 7.2 (the failure I've just posted).

[JDGrimes]

I have tried to reproduce this locally, with no luck.

[JDGrimes]

This appears to possibly be related to the latest build update, see travis-ci/travis-ci#8913. I guess we should try reverting to the old infrastructure and see if that fixed the issue.

[JDGrimes]

Yep, this does appear to work on the previous build version, although we do have some test failures for some reason (possibly related to recent code changes).

[JDGrimes]

The PhantomJS version does appear to have changed.

On the new image:

PhantomJS version
2.1.1

On the old image:

PhantomJS/2.0.0

I wonder if that is related.

[JDGrimes]

It does indeed appear to be possible to work around this by installing PhantomJS 1.9.8. When installed but not aliased, the build still stalls.

[JDGrimes]

However, this only appears to work on the sudo enabled builds. If sudo is disabled, then it doesn't work, despite PhantomJS being installed properly. The build still stalls. So it appears to be a combination of things.