[buddypress-trac] [BuddyPress Trac] #5708: Broken Travis CI PHP 5.2 tests and improved Travis CI performance
noreply at wordpress.org
Fri Jun 13 22:51:04 UTC 2014
#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
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
> 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
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
> Can you clarify why the Travis-specific paths are required in define-
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/>
More information about the buddypress-trac