Fun with Travis CI and PHP projects

I know I should have done this a long time ago, but I finally got my hands dirty with Travis CI.  I wanted to set up a php project on github to use Travis CI to monitor the status, in case I forgot to run the tests prior to pushing.  Unfortunately it was not as easy as it’s made out to be.  But now that I’ve done it once, it’ll be easier next time.  So, here is how I tackled it.

First, creating an account and getting started was easy.  I simply clicked the “sign in” link on the Travis CI site and entered my github credentials which authorized Travis CI to connect to my account. (the site informs you exactly what Travis CI will have access to)  Once that’s done Travis gets all my repos, so I can then activate them for Travis CI.  If that doesn’t happen automatically there is a handy “sync now” button to coax Travis CI.

NOTE: To connect public repos you would use, while for private repos you would use  While pubic repos are free private ones cost money, though you do get 100 pushes free to get you started.

Second, it’s now time to click the + and add a new repo to be tracked by Travis CI.  After clicking you will be presented with a list of your repos to choose from.  It is simply a matter of turning the repo ON by clicking the switch.  I also clicked the wrench to select the option to “Built only if .travis.yml is present”.

Travis CI add repo

The structure of the app I added looks like this: (including all files needed for travis and unit testing)

Application structure

Third, I needed to create the .travis.yml file with the directives needed to make it all work.  Here is what my file looked like.

travis.yml file

Pretty simple.  Here is what it all means: I specified what language to use (php), and what versions of the language to test with (5.3, 5.4, and 5.5), I also instructed to have Composer install prior to any other scripts run (needed to ensure there was an autoloader, created by Composer), and finally I add the phpunit command and tell it where to find the phpunit.xml file (in this case it was in the tests directory).

Fourth, ensure that PHPUnit runs as expected locally.  Yes, you will need unit tests on your code.  That’s like one of the main reasons to do this in the first place.  Here is what my phpunit.xml and bootstrap.php look like:

phpunit.xml file

The phpunit.xml file is fairly simple.  It informs where PHPUnit can find the bootstrap.php file (same directory as a the phpunit.xml), and sets a whitelist of directory where code can be found (some use a blacklist and specify not to use the /vendor directory), and what directory to find tests in (the current directory).

phpunit bootstrap.php file

The bootstrap.php file specified by the phpunit.xml file is even simpler, as it only specifies where to find the autoload.php file created by the Composer install.

Fifth, take a quick peek at the settings for the repo on github and you will notice that Travis CI should be already set up and ready for something to be pushed.

github settings

Final, that’s it!  That is everything needed for Travis CI.  Of course this example is very simplistic, since the repo and tests are only on a single wrapper class I created.  But it’s good enough for a start, and if you need more the documentation is pretty good.  With these files created, all that remains is for me to commit changes to git, then do a push to origin at github.  Once the push to origin happens a Travis CI trigger at github fires and informs Travis CI to create a new build on a VM (virtual machine) then run the tests on the newest code.  After Travis CI finishes it lets you know with an email, and through the site. (green = good)

Travis CI feedback

One last thing you may want to do is add the Travis CI image to your at github.  This will allow you and others to see whether the current master branch had a successful build, or if it failed.

[![Build Status](](

Travis CI build status indicator


Simple reminder to keep it simple

This morning a tweet caught my attention prompting me to read this post by Gary Hockin also known as @GeeH. (There’s just something about that voice.[inside joke])  In the post he talks of his experiences while attempting to simplify code in a project, and in the process uncovers hidden dependencies that increased the codebase significantly in order to gain the benefit of a mere 100 lines of code.  He also highlights that in today’s mainstream PHP development, where many are using Composer to blindly include packages into applications, we may not fully understand code being pulled in with the consequence of accepting responsibility to maintain those additional packages as well.

I’ll wait a second while that sinks in…

Yes, that’s right.  If you include additional packages and libraries into your application you’re accepting the responsibility to maintain them.  No, I’m not saying you are responsible for contributing to the software package…unless you care to.  What I’m saying is you are now in charge of updating the software within your application, which now includes additional packages created by others.  As security holes get fixed, or new versions come out fixing bugs, it is up to you to ensure you update these packages in your applications which include them.

You’ve been living in a dream world Neo

Ha, didn’t think about that, did you?  If you did, Bravo, you’re behaving like a professional.  For the rest, welcome to reality.  Now go update the applications you’ve neglected.  But first a side note.

I’m not saying Composer is bad.  Actually I think the opposite.  Composer is awesome, and you should be using it if you’re not already.  As in the post by Gary above I’m simply saying it’s our professional duty to know what we’re asking Composer to do on our behalf.  Use it responsibly and do a bit of research so you’re not blindly including potential issues, bugs, security holes, and nightmares to maintain in the future.  Then if you’re satisfied with what you see, go ahead and “require” away.

But wait!  Don’t just look at the packages you’re including into your codebase.  Also take a look at their dependencies as well, because you are also accepting them in the process.  Know what you’re saying “yes” to.

Past knowledge

None of what I’m saying is new stuff.  A while back, in the beginning of 2012 (I thought it was earlier for some reason), Ed Finkler @funkatron wrote the original MicroPHP Manifesto to voice his concern over many frameworks starting to grow in size. (NOTE: Later there was a separate domain dedicated to housing the MicroPHP Manifesto, but I like the original better because the blog post associated with it helps highlight why it’s a concern.)  I encourage you to check it out and consider the meaning, and how it relates to your projects.

Again, nobody is saying large full frameworks are evil or other libraries should not be used.  The idea behind all of this is to caution, so you go in with your eyes open and “know” what you’re including in the codebase.  Know the responsibilities accepted by including other libraries.

Happy coding!

PHPUnit, Composer, PHPStorm, Oh my!

Installing PHPUnit within a project via Composer, then running tests through PHPStorm is not an intuitive process. However, with the right steps it’s actually pretty simple. Here is my story:

To launch the call for papers for the SunshinePHP Developer Conference it was a pleasure to use the OpenCFP project as a starting point rather than creating the entire thing from scratch.  While the project is still a “beta” with a few wrinkles to get ironed out, it’s still a pretty nice effort. (I have a pull requests pending, and another to submit.  Love open source!)

For my CFP I wanted a few more fields of information than the “out of the box” setup, so I quickly added them to the app.  However, doing this meant the included unit tests would fail.  But wait, I hadn’t run the unit tests yet!  I realized immediately how spoiled I had become with today’s modern frameworks with a testing method built in.  This little project did not have that luxury, so I would need to run the tests the old fashioned way, or let an IDE do it for me.  I decided to configure PHPStorm do it. (I’ll do the same for Zend Studio in another post later.)

The way OpenCFP was set up, using Composer, meant that PHPUnit was already placed in the /vendor directory as a requirement in the composer.json.  So rather than taking the lazy way out and using the PHPUnit already installed globally on my system, I wanted to use the latest PHPUnit within the project.  This requires 2 setup steps in PHPStorm.

Step 1

To start I needed to inform the IDE where to find the Composer autoload file and leverage the awesome PSR-0 goodness to autoload PHPUnit in the /vendor directory.  To do this I open the Settings via the icon on the toolbar, or by using the File->Settings menu item, or hitting the Ctrl+Alt+S keyboard shortcut.  Then in the Project Settings (top section) I expanded PHP to get the PHPUnit dialog.

PHPUnit setup in PHPStorm

Step 2

Now I had to add a Run/Debug Configuration for the project.  I did this by clicking on the toolbar dropdown and selecting Edit Configurations.

Edit Configuration

Once the dialog opened I clicked the “+” to add a run configuration, and select the PHPUnit type.

Choose configuration type

Now it was just a matter of adding the directory where the tests reside. (Name the configuration to your taste.)

Location of tests

All done!!!  Now I was able to run the tests simply by selecting the new run configuration defined in the dropdown, and clicking the Run button in the toolbar.

Good luck, and happy testing!