[buddypress-trac] [BuddyPress Trac] #5708: Broken Travis CI PHP 5.2 tests and improved Travis CI performance

[buddypress-trac]

#5708: Broken Travis CI PHP 5.2 tests and improved Travis CI performance
--------------------------+------------------------------
 Reporter:  netweb        |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+------------------------------

Comment (by netweb):

 Replying to [comment:1 DJPaul]:
 > What is `getenv( 'TRAVIS' )`?
 Travis CI includes a bunch of [http://docs.travis-ci.com/user/ci-
 environment/#Environment-variables  #Environment-variables] that can be
 used throughout testing scripts.
 > Does WP's own unit tests pass with HHVM? I thought about adding HHVM
 last time I touched the file but on reflection I decided until we *know*
 WordPress itself works properly on HHVM, it wasn't worth us testing
 against.
 No, not currently, HHVM & PHP 5.6 ''allow to fail'' testing will be in
 WordPress Core shortly #WP28301. So ''in theory'' once this is included
 iteration can be done so that the test do start to a) run and b) pass.
 > Similarily, if we decide to test against HHVM and there are errors, do
 we care enough about HHVM to fix them?
 I would say yes, there has been
 [https://core.trac.wordpress.org/search?q=hhvm work] to get WordPress
 running on HHVM and fully expect this to be a supported PHP version in the
 future.
 > If we do, we should make a plan to make that happen, and have someone
 responsible for fixes.
 > If we don't, what's the point running the tests? If someone wanted to
 start making it work, they could run the tests in their local HHVM-enabled
 environment.
 I would say because WordPress Core is working on HHVM compatibility we
 should follow suit, there may not be a detailed roadmap yet so I'd suggest
 we just ''roll with it'' ;)
 > We should probably also wait until the current issue with LIKE_ESCAPE is
 resolved so we have passing tests before we apply any of these proposed
 changes to the config. :) https://core.trac.wordpress.org/ticket/10041
 Either/or, none of the changes in this patch change the current tests per
 se, just speed improvements and the PHP 5.2 fix

 Replying to [comment:2 boonebgorges]:
 > - Change to git clones seems good to me
 > - fast_finish seems fine
 > - before_install seems good
 Cool
 > Questions:
 >
 > Can you clarify why the Travis-specific paths are required in define-
 constants.php?
 Because no matter how or what I tried I could not get PHP 5.2 to find the
 `wp-tests-config.php` file, I walked up, down, left, right, throughout the
 directory structure looking for it, never to be found, gave up and used
 the Travis CI environment variable to just explicitly declare it. I went
 back through a ton of Travis CI results trying to find the last time PHP
 5.2 actually did find the file and again, gave up looking so I have no
 idea when this became broken.
 > - Can you expand on the WP 3.7 point? I don't follow, and I don't see
 broken builds on 3.7.
 The previous config that @DJPaul implemented for ''disable WP_DEBUG for
 PHP 5.5 due to ext/mysqli E_DEPRECATED errors'' was disabling WP_DEBUG for
 all WordPress versions running under PHP 5.5, we only need to do this for
 WordPress 3.7.x branch, 3.8.x included a fix for this, and 3.9.x full
 support for mysqli was added.
 > - I can't see at a glance what it is in your patch that's fixing the
 builds for PHP 5.2. Can you clarify?
 The PHP 5.2 tests could not find the `wp-tests-config.php` file, so the
 PHPUnit tests would never start, it was lost, but now is found ;)

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5708#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac