ramblings on PHP, SQL, the web, politics, ultimate frisbee and what else is on in my life

Travis, CI for OSS

Continuous integration is one of these topics that had a slow start, but in recent years has really taken off. The slow start is likely to be attributed to the fact that it was perceived as hard to setup and maintain. But solutions around Jenkins and Sismo are making it easier and easier. But thanks to the new Travis CI service, its now essentially so easy that there is no excuse not to use CI for PHP projects, at least if you are hosting your OSS code on github.com. What makes this service so crazy cool is that you can run your tests against multiple PHP versions, multiples databases (heck even RabbitMQ) and against multiple versions of various libraries. For a prime example of this check out Doctrine2 on Travis. You can configure tons of stuff, like various ways to get notified in case a build fails and you can even include a little status icon that gets updated automatically into your project description. In short this is amazingly awesome and again its free to use for any open source project out there!

Maybe a short back story. Alvaro poked me I think earlier this week about Travis. I was immediately won over and poked Pascal who is working on the CI setup for Symfony2. I added a few Liip Bundles, while Pascal tackled the bigger projects like Symfony2 and Doctrine2. The Travis team, especially of course PHP native Loic, where super helpful in the #travis channel on Freenode IRC. Pascal figured out how to run Doctrine2 against multiple databases. Loic showed me how to run against multiple Symfony2 versions and I proceeded to add several FriendsOfSymfony Bundles. All within a single week!

So here are some things I learned in the process. First up it is a pity that Github doesn't provide oauth tokens for organizations. As a result I ended up creating a dedicated github user for the Liip Bundles that points back to a closed mailing list for the notifications. For FriendsOfSymfony I am simply using my personal token. Note for personal repositories there is a nice UI on travis-ci.org to enable/disable integration. For organizations you will have to go to the organization repository and under "admin" click on "service hooks". Then click on "Travis", then scroll back up leaving domain empty and finally your username and token as seen on the Travis CI profile page.

Second of all I learned that google groups are painfully annoying for this use case as its impossible to allow an automated service to post to a moderated list, as there is no way to cannot confirm a mailing list invitation. Oddly enough I can't even set the list to moderated for non members, since I was unable to get google groups to not require moderation again for a once moderated sender. Speaking of notifications, some people *cough* Jordi *cough* complained about me spamming the FriendsOfSymfony mailing list with tons of emails. In general email notifications are only send if a build failed or if I build just switched from failed to success. So ideally once we get a Bundle passing, we should never see another email unless a commit breaks the build.

Anyway, I think they included lots of Bundle configs in the official docs but I just briefly want to touch on the topic of vendors and autoloading. So right now I setup all Bundles to contain a simple vendors.php script inspired by the script contained in the Symfony2 repository. I also added an autoloader.php.dist as the default mechanism for autoloading in the tests. But the user can define an autoloader.php to override the default which is useful to be able to run the tests against a local checkout of the dependencies without having to run the vendors.php. But the future is much brighter as Loic is looking to add composer support. Once that is in place it will no longer be necessary to write separate vendors.php script or autoloaders since composer can handle all of that for you.

Another thing that will come soon hopefully is to define a url to the ".travis.yml" file, like via a gist, so that its no longer necessary to store this file within the repository. Personally I do not mind this file at all, since it also serves as documentation on how to get the test to run, but I am sure some people might feel the this is ugly *cough* Jan *cough*. At the same time these days most of us have a "phpunit.xml.dist" file already and this is no different to me.

Anyway this service is really exciting and I hope that other projects will also adopt this tool quickly. Even if these projects have their own CI setup already, I think it doesn't hurt to add Travis as well since this way its also easy for people that work on a feature branch to setup the CI hook if all the configuration is already done for them. As a matter of fact if all goes well we might start asking submitters to include the status image as part of their PR's. This is way superior to the current check list item we have, since I must admit when I send a PR for the first time I may run the tests, but when I do minor tweaks I made forget to run the tests again and so my claim that the tests pass might get outdated.

Update: Forgot to mention that one of the Travis guys will give a short tech talk about Travis at Liip on the 17th at 11:30 CET. You can attend at any of our main locations in Zurich, Fribourg and Lausanne and I will check if its possible to put up a live stream.

Update2: Just heard that the Travis team might work on PR support as well.

Update3: Travis CI guys also have an idea for how to make it possible to have the easy flip switches for all organizations and their repositories a given github user has admin rights to.


Re: Travis, CI for OSS

Hi Lukas, make sure you check out the new kid on the block: Cintient. It's a dead simple PHP CI server, self-hosted. It's premise is somewhat different than Travis (and even Jenkis and CC for that matter) in that it tries to keep it as simple and clean as possible. (Although not as simple as Sismo, which I didn't know until I read this). It's up on GitHub and is now in Beta. https://github.com/matamouros/cintient

Have fun.


Re: Travis, CI for OSS

Good one. I need to try it for my pet project (Sf2 bundle in fact), but still, vendors handling is quite rough for me, composer would be great :-)

Re: Travis, CI for OSS

You can also use submodules of course, I just find them less transparent since there is just a commit hash and not a nice branch/tag I can look up in a file.

Re: Travis, CI for OSS

Yup, that's right. Anyway, I used vendors.php you've used in FOSUserBundle and it works smoothly for my newsletter bundle. I'm impressed how easy it is to set up build for project hosted on github :-)

Re: Travis, CI for OSS

Awesome! I just had to spread the news here: http://www.testically.org/2011/11/16/travis-ci-continuous-integration-to-go/

You are absolutely right. There is no more excuse!"

Re: Travis, CI for OSS

Good info. I just shared this with my friend. Thanks

Testing with Travis PRO

This goes to prove that us developers are a lazy bunch. We dont't see a major conversion until the tedious parts are automated. :)

I am beta testing their Travis PRO service, for private repositories, and so far I am really pleased with it. If you're looking to test your Symfony2 app with Travis PRO I wrote up a post about it with some gotchas: