I recently learned about Travis CI[in the past 6 months] which removed a
large number of testing issues I've faced in the past[PHPUnit has
changed so much from version to version, that at times one PHP package's
tests require a specific downlevel PHPUnit to run, while another
required a different downlevel PHPUnit...leading me to frustration when
working on both at the same time!]
With the combination of Composer, Github, and Travis CI - I can set it
up to install a specific version of PHPUnit and whenever I push a
commit, Travis runs the tests for me....much easier.
So when Travis CI added support for selecting HHVM as a PHP Version I
was curious on how it compared to regular PHP. Grabbing my favorite
PHP framework[Joomla] I created a new branch and added hhvm as a PHP
version.
The biggest problem I ran into was that the current hhvm release is very
downlevel on features which caused a lot problems in the unit tests[a
lot of Image processing tests blew up]. Fortunately, Facebook
maintains an apt installable copy of hhvm-nightly, so with some extra
build scripts I was able to set up some conditional apt-get scripts to
make sure hhvm-nightly is installed:
https://github.com/garyamort/joomla-framework/tree/hvmmaster/build/travis/scripts
I also had to heavily modify the travis configuration:
https://github.com/garyamort/joomla-framework/blob/hvmmaster/.travis.yml
I learned that with travis, many of the commands for each
stage[before_install, install, before_script, and script] are at the
same time. So if your running 3 scripts for the "install" stage, they
run at the same time, but if/when one of them fails the error is
reported as being from the script started first and still running.
IE: your running a.sh, b.sh, and c.sh
a.sh finishes executing
b.sh and c.sh are still running
c.sh aborts with a vague error message
Travis reports the error message as coming from b.sh and aborts the job.
Plus if c.sh depends on something b.sh is configuring, it will fail. So
careful placement of scripts to ensure that they finish in the correct
sequence is important.
There were a few interoperability problems between Composer and
hhvm-nightly when it came to how the version string was formatted - I
reported it to both groups and the facebook team were very quick about
reaching out to the Composer dev to find out what version string format
he preferred and then they updated their build process to produce it.
With all the major issues taken care of, it was just a process of fixing
a handful of little incompatibilities to get the test to run.
In the end, I found it rather impressive that hhvm took about half the
time to execute. Generally it took PHP almost 6 minutes to run all the
unit tests. HHVM was able to run them in under 3 minutes.
Even if you don't plan on using hhvm for production - adding it to your
unit testing is very beneficial. Most of the changes I had to make in
order to get the unit tests to run were not differing published
features[the string access as an array thing for example] - but instead
they were broken/undocumented features in PHP 5.3/5.4. For example,
PHP has some VERY strange ways of handling using private methods for
autoloaders. Because the documented autoload features specify that you
must use public methods for autoloaders, HHVM adhered to the spec and
thus would break there.
It's somewhat like how you can use Clang to compile your C code to find
all the bad coding practices which directly contradict the C standards
but work anyway if you compile your code with GCC. Clang has added a
bunch of flags to allow code to be compiled in the "broken" gcc
supported way - but if you use it in it's default config you can find
all your "broken but working" code.
Just curious if anyone has anything actually in production using hhvm?
Or even just playing around with it.
-Gary
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show-participation
