The Travis CI Blog

Announcing Pull Request Support

2012-05-02T00:00:00-07:00

Josh and José at Railsberry

Some of our team just got back from two pretty intense weeks of conferencing. We had an amazing time speaking at the JAX, Railsberry and RailsConf and getting our hands on two of the Ruby Hero Awards. A couple of announcements were made live on stage and you might have heard a few rumors coming out of the conferences. So let me wrap up one of them for you.

I'm pretty excited about this one, as I've been working on it over the last weeks. This is the first feature to be sponsored by our impressing Love Campaign. While the promise of adding more languages actually came true, this was mainly done by excellent community contributions and the hard working Michael Klishin.

How We Use Pull Requests

A typical Pull Request

When Github first announced Pull Requests 2.0, it wasn't obvious right away how truly amazing this feature is for us developers.

Pull Request 2.0 Workflow

It revolutionized the workflow by making the patches part of the discussion. This actually led to code reviews from other contributors while working on a feature, rather than once you think you're done working on it.

Think of it as bringing agile development to Open Source contributions. Wikipedia even calls this new and social approach The GitHub revolution.

It really only had one downside: Merging still was as complicated as before. You have all the fancy review tools and still have to go into the terminal and type a couple of commands. This quickly became rather tedious.

The Merge Button

GitHub's Merge Button allows merging Pull Request form the Web Interface

GitHub, once more, came to our rescue by adding the Merge Button.

The Merge Button Workflow

By pressing a button on the website, one could easily merge Pull Requests without having to drop to the console.

This feature, combined with the Fork and Edit button, made contributing a no brainer.

Especially the roundtrip time for documentation fixes, like typos, broken examples, etc. went down to sometimes just a few seconds.

Contributing a fix became as simple as two clicks on GitHub. Making contributions that easy lowers the barrier and thereby strengthens the Open Source ecosystem.

You probably can tell by now how much we love this feature.

The Merge Button is a dangerous tool, trust Boromir.

There is a downside, though. The Merge Button is not really usable for anything but documentation.

If you click the Merge Button for anything touching code, you risk breaking upstream. Maybe this seem acceptable at first, after all your CI will tell you if you broke anything. You are using CI, right?

However, it not only renders your mainline pretty unstable, it also changes responsibility. All of a sudden you as a maintainer are responsible for fixing the issue, if only by reverting the commits.

So you're back at merging locally and checking out if everything works. Maybe you even push on a feature branch first, just to trigger a CI run before merging.

Enter Travisbot

The Perfect™ Workflow

It would be really cool to just know if the Pull Request breaks anything, without all the hassle.

This is basically what we've implemented. We test every mergeable Pull Request and have our friendly Travisbot leave a comment in the Pull Request discussion.

That way you can now safely press the Merge Button. That is, if it doesn't break anything, of course. And if it breaks, it's not necessarily the maintainers (or worse, the users) responsibility to deal with the issue.

Or imagine having a broken upstream and someone submits a Pull Request fixing it.

Pre-Merge Button Workflow

In contrast to most self-made solutions out there, we actually test the merged version, rather than just the fork or feature branch. Thus, we also take into account changes made upstream after the repository has been forked.

We will also re-run the tests whenever new commits are added to a Pull Requests (yes, this works fine with force pushes and rebases). Also, it pretty much works with anything that is mergeable, might it be a branch, tag, fork, etc. As long as you see the green Merge Button, we can test it.

Are we there yet?

This feature is still under development. The described functionality works just fine, but we have plans for future extensions.

For instance, we would like to leave a comment whenever master is updated and give you the option to automatically rerun the tests with the new merge commit.

I WANT THIS NOW!!

If you made it this far in the blog post, you probably want it for your repository, and you want it now. Good news! We started unrolling this feature.

Let us know if you want this feature

As we are still improving it, and are not sure if we can stand the load of activating it for everyone right away, we are turning it on on a repo per repo basis.

Please note that we start unrolling for those people, that donated, so I was actually able to work on this. So, if you donated and want this, just let us know.

If you didn't donate, but still want to use this feature right away, our Love Campaign is still running.

Metrics, Monitoring, Infrastructure, Oh my!

2012-04-02T00:00:00-07:00

Making sure Travis always runs smoothly all the time has become one of our most important tasks over the recent weeks and months. As a distributed system, there are a lot of moving parts, and we're putting more and more eyes on every single piece to make sure they do their job. Obviously there's no need to keep this a secret, so let's talk about some recent changes to Travis' infrastructure.

Case in point. A recent deployment broke updating profiles temporarily. Here's a pretty graph showing the pretty much exact point in time when we deployed and the spike in the number of errors.

You can see the initial spike, which represents a sudden increase in application errors. We rolled out a fix shortly after, so things quieted down somewhat. There's still some noise though, still several 500 errors popping up in our logs. It took a while to fix those, but you can see it eventually ebbed off after another deployment.

This is a pretty powerful tool. We added putting more and more metrics on the moving parts in Travis. If you want to know why, you should read this blog post from the Flickr engineering team, and you should definitely watch Coda Hale's talk Metrics, Metrics Everywhere!.

All these metrics tell us what's going on inside Travis in real time, and they show us historical growth so we can spot patterns, capacity issues and unexpected spikes. Here's a another pretty graph of all our internal notifications. These metrics are pretty new and were put in production last Friday, but it's still something to enjoy (click to enlarge).

All these pretty graphs are courtesy of Librato Metrics, who were kind enough to offer sponsoring their service for Travis CI. As we add more and more metrics to Travis they'll automatically show up in Librato and will be graphed in real time.

The fun doesn't stop there. To make it possible that we can properly graph 404 and 500 errors, we added custom logging. Rails' default logging is not very helpful for production systems, as it produces a lot of noise. Thanks to Rails 3 and the new notifications introduced with it, it's now possible to override what Rails does by default and hook in your own logging. That's exactly what we did, and the result is lograge, a little library that turns Rails' logging events into a neat, single line per request. You can read all about it in Mathias' blog post.

This helped streamlining our logging, making it more and more useful along the way. All our logs are aggregated in Papertrail, who were also kind enough to offer sponsoring their services for Travis.

This allowed us to do something pretty nifty. Eric of Papertrail wrote a neat little metrics library for Ruby called Metriks, which we started using in Travis. It collects metrics and can dump them to either a log file or directly export to Librato Metrics or Graphite. It can also show selected metrics in the process status, so whenever you run ps ax, you can see the current number of requests per second, or pretty much whatever you fancy. You should go and read Eric's blog post on the library.

The really neat bit is that Metriks can log the collected metrics to the log file. Papertrail can then look for patterns in the aggregated logs and react accordingly, in this case triggering a webhook where the metrics are aggregated and eventually stored in Librato Metrics. Did that just blow your mind?

Here's how that looks coming into Papertrail (click to enlarge).

This little trick utilizes Papertrail's filters and webhooks alerts, and a nifty little app that Eric built to accept the filtered output when a metric is found in the logs.

Why would we want to do that? Simply because it decouples the fact that we're collecting from where the metrics need to be stored. It's a fully asynchronous process, and they'll simply show up in Librato eventually. We can also put a filter on anything in Papertrail and have occurrences in the log be directly graphed in Librato's Metrics. It's pretty awesome. Every bug fixed is a new opportunity to add more graphs and add more logging.

For good measure, here's another graph showing the requests we're receiving from Github. It includes the received, accepted and rejected pushes.

The beautiful bit is that we can take any metric and correlate it with others. That's a pretty powerful tool to find problems in infrastructure.

This is far from all of it, but it's a start. If you want to know more about why Mathias is so obsessed with metrics and monitoring, you should read his blog post about it. See you in the next installment about how we're adding more mustache to Travis' infrastructure.

Migrating CI Environment to Ubuntu 11.10

2012-03-27T00:00:00-07:00

Keeping Up With the Times

When we first started using virtual machines for Travis CI (around June 2011) we decided to use Ubuntu 10.04. This worked perfectly, but by the fall of 2011 10.04 started showing its age. Our users kept asking for more recent versions of certain tools and libraries which were challenging to provide without building and maintaining a myriad of Debian packages. So in November 2011 we migrated all VMs to Ubuntu 11.04 which solved the problem.

Now it is Spring 2012 and the time to move on to 11.10 is drawing close. We want to explain briefly how Travis CI will migrate to it, why we are doing it and what may change for your project.

Why Migrate?

With Ubuntu 11.10, we will be able to provide more up-to-date versions of tools and services in our CI environment, including:

OpenJDK 7 alongside OpenJDK 6 (this is still a work in progress)
PostgreSQL 9.1 + updated extensions
CouchDB 1.1
Firefox 11

In addition, we won't have to use 3rd party apt repositories or compile certain tools from source, which greatly reduces our maintenance burden, for example:

Haskell Platform
Maven 3

Staying One Step Behind, Intentionally

Our users are mostly software developers and they tend to like to staying up-to-date with tools, services, libraries and so on. However, production environments are rarely on the bleeding edge. So for CI in general, and Travis CI in particular, it is important to maintain a balance: not too old, but not too new either. This is why Travis CI is intentionally about 6 months behind Ubuntu releases. It gives developers several months to catch up with recent changes, fix issues and push out new releases.

Important Changes in 11.10

GCC

One of the biggest changes with every distro release is GCC version changes. 11.10 ships with GCC 4.6. This version is known to be more strict than previous releases and some tools and libraries may need minor changes when compiled with -Wall. Judging from the experience from one of our team members, most popular tools were updated in the beginning of this year.

OpenSSL

Another important change OpenSSL version. 11.10 ships with OpenSSL 1.0 by default, but even more importantly, disables SSLv2 support. SSLv2 is very old (released in 1995), there were 4 updates to the spec after it: SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. In addition to that, SSLv2 contains several known security flaws and all new distributions either already dropped support for it or will be dropping it very soon.

PHP 5.2

Because of the SSLv2 change explained above, we had to disable SSL support for PHP 5.2 and 5.3.2. PHP 5.2 is no longer maintained by the PHP Core Team and we were faced with a decision: either drop it completely or patch and maintain it to work with OpenSSL 1.0, or disable SSL support for it.

PHP 5.3.10 and 5.4.0 are maintained and work with OpenSSL 1.0 without modifications, and have OpenSSL support enabled, just like they have today.

The Road to 11.10

On April 6th, 2012 we plan to update all our VMs to use Ubuntu 11.10. We will provide the same set of tools, services, and libraries, but some of them will be newer than what we have today. Most maintained software should work without any changes on your part. If you experience any issues please drop by #travis on irc.freenode.net and we will do our best to help you.

You can also try a minimalistic 11.10 image using Virtual Box and sous chef or Vagrant with our 11.10 base box.

Happy testing!

The Travis CI Team

Announcing Haskell project support

2012-03-11T00:00:00-08:00

Travis' Eleven

Today we are happy to announce support for an 11th language on Travis CI: Haskell. Known for its concision and very advanced type system, Haskell has been attracting some of the brightest minds in the programming languages research community for a couple of decades.

Haskell can be found in code analysis tools, DSLs for cryptographic algorithms, secure networking stack implementations, network applications, plenty of financial software and even system administration. So Haskell sounds like the right candidate to complete Travis' Eleven.

Wait, What Is Travis CI Anyway?

Travis CI is a distributed continuous integration for the open source community. It is integrated with GitHub and offers first class support for multiple technologies. Our CI environment provides many tools, libraries, and services (MySQL, PostgreSQL, Redis, RabbitMQ, MongoDB and so on), and you don't have to bother setting up your own CI server.

You can watch build logs in near-real time in your browser, access logs later, and even link to log line numbers (for example, when reporting an issue).

Thanks to Github integration, Travis CI lets your contributors effortlessly add their development forks to test work-in-progress branches and makes your CI status very visible to the community thanks to our CI badges.

Started in early 2011, Travis CI has since run half a million builds for over 7,000 open source projects, including Ruby, Ruby on Rails, RubyGems, Node.js, Leiningen, Symfony and many more.

Getting Your Project on Travis CI

Travis CI currently provides Haskell Platform 2011.04 (with GHC 7, Cabal, Happy, Alex and so on). To get started, you need to add one file (.travis.yml) and the Github hook as described in the Getting Started guide. If your project uses Cabal, a minimal .travis.yml would look like this:

language: haskell

Travis CI will run the dependency installation command:

cabal install

and then the testing commands:

cabal configure --enable-tests && cabal build && cabal test

It is possible to override these commands and add new ones to the build lifecycle, please refer to our documentation, which now includes a guide dedicated to Haskell.

Build workflow

By default Travis' build workflow is

Clone your repository from GitHub
(If applicable) pick language/runtime version to use
Run before_install commands (can be more than one)
Install dependencies. Travis will use cabal install by default. You can override the command using the install key in your .travis.yml.
Run one or more before_script commands.
Run the script command, e.g. cabal build && cabal test. This too can be overridden in .travis.yml.
Report the build has finished running.

Learn more

To learn what tools and services (mysql, postgres, riak, etc.) are available in the CI environment, refer to the CI environment guide.

If you need help, feel free to join #travis on irc.freenode.net, ping us on Twitter (@travisci) and ask questions on our mailing list.

Thank You Contributors

We would like to thank Alessandro Vermeulen for his help with making Haskell support on Travis CI a reality.

The Great Bundler 1.1 Upgrade

2012-03-09T00:00:00-08:00

The Great Bundler 1.1 Upgrade

As you possibly have heard, Bundler 1.1 was released a few days ago and is no longer vaporware, huzzah! We want to explain briefly how Travis CI will migrate to it, and how you can upgrade early if you want to.

Key Improvements in Bundler 1.1

Bundler 1.0 is often criticized for being a tad slow. One of the reasons was due to the large number of requests Bundler 1.0 issues to rubygems.org to resolve the dependency graph. Bundler 1.1 uses a new and improved rubygems.org API to significantly reduce the number of network requests, and in some cases it can even avoid hitting the network altogether.

Where We Are Today

Travis CI Ruby VMs have Bundler 1.0 preinstalled. If you have a small Gemfile then this should be perfectly fine for you, but if you have a larger more complicated Gemfile then your build might benefit from Bundler 1.1.

To update Bundler before dependencies are installed you can do:

before_install:
  - gem install bundler

And thanks to virtual machine snapshotting these changes won't affect subsequent builds.

Migrating to 1.1

On March 14th, 2012 we plan to update the Ruby VMs to use Bundler 1.1. If you experience any issues with Bundler 1.1 please report these to the Bundler team.

If for some reason you want to continue using a previous Bundler version you can downgrade using the following technique:

before_install:
  - rvm @default,@global do gem uninstall bundler -v 1.1.0 -x
  - gem install bundle --version '~> 1.0.0'
  - bundle --version

Happy Friday!

The Travis CI Team

Announcing Python and Perl support on Travis CI

2012-02-27T00:00:00-08:00

Just shy of a week ago we announced support for Java, Scala, and Groovy. Well, we thought to ourselves 'we already support 8 languages, why not more?', and MOAR you shall have!

Today we are happy to announce first class support for Python and Perl projects!

Adding support for Perl and Python was a no brainer for us, not that it was easy, because it wasn't, but that both languages were sought after by their respective communities and complete the quest for the three P's (PHP, Perl, and Python).

Perl, which has been around since 1987 (Genesis "Land Of Confusion")and has a toolset just as strong and mature as its community. For example, the Perl community has had a variation of Travis for the last 10 years called CPANTesters, with the difference being that CPANTesters tests releases while we test active development.

Python, around since the early 90's (think MC Hammer "Too Legit to Quit", 1991), and in fact it's OLDER than Java! It is used for pretty much EVERYTHING you can think of, from research at CERN, to build website (YouTube and DISQUS), scripting for Games (Battlefield 2), and scripting for Graphics programs (Autodesk Maya, GIMP, Panda3D and Blender to name a few). Pretty much, you have used Python and you didn't even know it!

Wait, What Is Travis CI Anyway?

You can watch build logs in near-real time in your browser, access logs later, and even link to log line numbers (for example, when reporting an issue).

Started in early 2011, Travis CI has since run half a million builds for over 6,000 open source projects, including Ruby, Ruby on Rails, RubyGems, Node.js, Leiningen, Symfony and many more.

Getting Your Python Project on Travis CI

Travis CI provides multiple Python and Perl versions to test against. To get started, you need to add one file (.travis.yml) and the Github hook as described in the Getting Started guide. A minimal .travis.yml would look like this:

language: python
python:
  - "2.6"
  - "2.7"
  - "3.2"
# command to install dependencies
install: pip install -r requirements.txt --use-mirrors
# command to run tests
script: nosetests

It is possible to add new commands to the build lifecycle, please refer to our documentation, which now includes a guide dedicated to Python.

Getting Your Perl Project on Travis CI

Travis CI provides three Perl versions to test against. To get started, you need to add one file (.travis.yml) and the Github hook as described in the Getting Started guide. A minimal .travis.yml would look like this:

language: perl
perl:
  - "5.14"
  - "5.12"

Travis CI will will run widely used

cpanm --installdeps --notest .

command to install your project's dependencies. For running tests, Travis CI will try to detect Build.PL or Makefile.PL file in your repository root and will run either

perl Build.PL && ./Build test

perl Makefile.PL && make test

It is possible to override these commands and add new ones to the build lifecycle, please refer to our documentation, which now includes a guide dedicated to Perl.

Build workflow

Travis' build workflow usually is

Clone your repository from GitHub
Pick language/runtime version to use
Run before_install commands (can be more than one)
Install dependencies. This will use cpanm for Perl and pip for Python. You can override the command using the install key in your .travis.yml.
Run one or more before_script commands.
Run the script command, e.g. perl Makefile.PL && make test. This too can be overriden in .travis.yml. Python projects are required to provide script: command.
Report the build has finished running.

Learn more

To learn what tools and services (mysql, postgres, riak, etc.) are available in the CI environment, refer to the CI environment guide.

If you need help, feel free to join #travis on irc.freenode.net, ping us on Twitter (@travisci) and ask questions on our mailing list.

Thank You Contributors

We would like to thank Donald Stufft, Kenneth Reitz, Jannis Leidel and David Reid for helping us making Python support happen and initial field testing.

Perl support wouldn't be possible without amazing work and advice by Magnus Holm, Jonathan "Duke" Leto (also a big YAY for adding Parrot to Travis CI!), and Xavier Noria.

Also, if you have a spare minute, send a HUGE thanks to Michael Klishin who works day and night (seriously, we can not figure out when he sleeps, or if he sleeps!) maintaining the VMs and making sure they are up to date. He was the driving force behind adding support for JVM languages (first Clojure, later Java, Scala, Groovy), and was instrumental in adding Python and Perl support. So please send him a tweet to say thanks, because without Michael we would still be at just Ruby support!

Next steps

Python and Perl support brings the total number of languages supported by Travis CI to 10. We love adding support to even more languages, but we think for now we need to focus on features like pre-tested pull requests that will benefit all projects, regardless of the language.

If you want to help us make Travis CI even better, consider making a donation.

Announcing Java, Scala and Groovy project support on travis-ci.org

2012-02-21T00:00:00-08:00

Travis CI started in early 2011 as a service for the Ruby community with the simple vision to make CI easy for OSS libraries and services. It wasn't long until we added support for Erlang, Clojure, Node.js and PHP. And, in fact, it is easy to build many other projects by supplying your own commands.

Today we are excited to announce support for Java, Scala, and Groovy!

The JVM ecosystem is very vibrant with multiple exciting languages maturing and being adopted by companies far and wide. In fact, since November 2011 Travis started using the JVM (JRuby) for several of our applications. The JVM and JRuby gave us access to a very solid runtime, as well as a vast selection of stable libraries, helping us to keep up with the growth over the last year.

Wait, What Is Travis CI Anyway?

You can watch build logs in near-real time in your browser, access logs later, and even link to log line numbers (for example, when reporting an issue).

Started in early 2011, Travis CI has since run half a million builds for over 6,000 open source projects, including Ruby, Ruby on Rails, RubyGems, Node.js, Leiningen, Symfony and many more.

Getting Your Project on travis-ci.org

Travis CI currently provides OpenJDK 6, Maven 3, SBT 0.11.x and Gradle (currently 1.0 Milestone 8). To get started, you need to add one file (.travis.yml) and the Github hook as described in the Getting Started guide. If your project uses Maven or Gradle, a minimal .travis.yml would look like this:

language: java

for Java, or

language: groovy

for Groovy and so on. Then Travis will see if you have a build.gradle or pom.xml file in your repository root and will run the standard dependency installation and testing commands, like

mvn test

gradle check

It is possible to override these commands and add new ones to the build lifecycle, please refer to our documentation, which now includes guides dedicated to Java, Scala and Groovy.

Build workflow

Travis' build workflow usually is

Clone your repository from GitHub
(If applicable) pick language/runtime version to use
Run before_install commands (can be more than one)
Install dependencies. Travis will try to detect whether project uses Gradle and SBT and run their respective commands, falling back to mvn install. You can override the command using the install key in your .travis.yml.
Run one or more before_script commands.
Run the script command, e.g. gradle check or mvn test, falling back to ant test. This too can be overriden in .travis.yml.
Report the build has finished running.

Support for multiple JDKs in the Travis CI Environment

travis-ci.org currently provides only one JDK. This is not on par with our support for Ruby (a dozen of versions/implementations), Erlang (several OTP releases) and so on. We will add support for testing against multiple JDKs near in the future.

Note that Clojure and Scala build tools allow testing against multiple versions and it is just as valid for Travis CI. This is documented in our guides:

Learn more

To learn what tools and services (mysql, postgres, riak, etc.) are available in the CI environment, refer to the CI environment guide.

If you need help, feel free to join #travis on irc.freenode.net, ping us on Twitter (@travisci) and ask questions on our mailing list.

Thank You Contributors

We would like to thank Gilles Cornu for doing most of the work on the Scala builder and updating our SBT Chef cookbook to 0.11.x.

Next steps

We don't want to stop here! There are so many other fantastic languages to add, and if all goes well we should have Perl and Python support around the corner. And if you want to help out, donating to Travis CI will make it happen sooner.

Discuss on Hacker News

You can discuss Java, Scala and Groovy support on travis-ci.org on Hacker News

Announcing "first class" PHP project support!

2011-11-13T00:00:00-08:00

Today we are happy to announce first class PHP support with Travis CI.

It includes all the same features Ruby, Erlang and Node.js projects enjoy today, including:

Easy to get started and integrates with GitHub.
Test against multiple databases and services, including Mysql, Postgres, Redis, RabbitMQ and many more.
Test your projects against multiple PHP versions.
Build results are publicly available online so you can link to them in your bug reports, including line numbers.
Notifications the way you want them! (email, IRC, and webhooks)

Over the last several weeks many nice folks from the PHP community have been working with the Travis team and it would not be possible without all the help from Loïc Frering and Pascal Borreli. Till Klampaeckel has helped us set up phpfarm and pyrus and test drive the whole thing. Álvaro Videla and Lukas Kahwe Smith also helped us a lot by running some of the Friends of Symfony projects on Travis early on. Pascal also got Symfony, Twig, Silex, Doctrine and Monolog test suites up and running on travis-ci.org (we hope his patches will be accepted upstream).

Having all those projects building fine for several days makes us confident that we are ready to ship this feature.

Please see our initial documentation for PHP projects and the rest of the guides. We tried to link to as many real world .travis.yml examples to demonstrate all the features in action.

In addition, we have a couple of machines lined up that we will be running PHP builds on. One of them is Shopify: they donated us a worker we have been using for Node.js projects. Another one is ServerGrove, experts in PHP hosting and specifically frameworks like Symfony and Zend Framework: they donated us one more machine to run PHP builds on.

If you have questions, find us in #travis on irc.freenode.net, we will be happy to answer them. To stay up to date with new announcements, CI environment software updates and more, follow us on Twitter and join our mailing list.

We hope you enjoy using Travis for your open source projects as much as we do. Go add your PHP projects to Travis CI and recommend your fellow PHP developers to do the same!

The Travis Team.

Spread the word!

Feel free to discuss and upvote on Hacker News

Updates

Doctrine is now on Travis: doctrine2, common
Monolog is now on Travis Monolog

VM environment upgrade, Nov 11th, 2011

2011-11-11T00:00:00-08:00

travis-ci.org Ruby workers were upgraded, here is what's new:

Ruby Workers Changes

Updated Rubinius 2.0 from 2.0.testing branch
RabbitMQ 2.7.0

Rubinius team was busy making GC and full CPU concurrency improvements as well as upgrading Ruby standard library for their 1.9 mode. Give it a try by testing your Ruby projects against Rubinius!

Node.js Workers Changes

Node.js workers were upgraded, too:

RabbitMQ 2.7.0

Follow Us on Twitter

To get regular updates about travis-ci.org environment upgrades and other developments, follow Travis CI on Twitter and watch our Chef cookbooks repository on GitHub.

MK on behalf of the Travis CI Team.

Announcing "first class" Node.js project support!

2011-11-09T00:00:00-08:00

One of the things people keep asking us is when language X will be a first class citizen on Travis-CI. While it has been possible to build Node.js and C++ projects on Ruby workers for a while, it is not very convenient or intuitive, and such projects will not get the killer feature of travis-ci.org: testing against multiple versions/implementations. So we have good news for the Node.js community: Node.js is gaining first class support on Travis-CI, joining Ruby and Erlang.

Thanks to the hard work by Harry Brundage and the Travis core team, it is now possible to test your Node.js projects against multiple Node versions (currently 0.4.12, 0.5.8 and 0.6.0). We use NVM ("RVM for Node.js") project and Chef cookbooks to enable to easy switching of Node.js versions.

In addition, Shopify now sponsors a machine that we will be running five Node.js workers on. Please thank them by sending a loving tweet or two to @Shopify :)

How do I test my project against multiple Node.js versions?

To test your Node.js project against multiple Node versions, add a '.travis.yml' file to your GitHub repository and add the following to it:

language: "node_js"
node_js:
  - 0.4
  - 0.5
  - 0.6

When you define "node_js" as the language it tells Travis to switch the Node.js version (nvm use 0.4), install the dependencies of the project (npm install), and run the tests (npm test). If you define multiple Node.js versions to test against, like the above example, Travis will create a matrix of test configurations, in this case three builds will be queued. Or you can leave out the node_js versions to test against and Travis will use 0.4 by default. If your project is not yet Node 0.5 or 0.6 compatible, you can exclude those versions. The same goes for project that want to only support 0.6, for example.

See Shopify's Batman as well as Martin Wawrusch's hook.io-blueprint-in-coffescript and hook.io-amqp-listener projects as examples.

The Workflow

Travis' Node.js builder will do the following as part of the build process:

Clone your repository from GitHub
Pick Node.js version to use
Run before_install commands (can be more than one)
Install dependencies using npm install [npm_args] or whatever you provide in the install key in your .travis.yml file
Run before_script (can be more than one script)
Run install command if you provided it in your .travis.yml. By default it is npm test if it finds package.json in the repository root or make test otherwise.
Run after_script (can be more than one command)
Report the build has finished running

Most of steps in the workflow can be overriden by projects that need it. We recommend you to use defaults when possible, though.

For more information on what is available in terms of services (mysql, postgres, riak, etc.), or how to configure your builds or matrix, visit the docs site.

Next steps

We have support for more languages in the works, one of which we hope to ship really soon, so stay tuned!

In conclusion (a.k.a lots of <3 <3 <3)

Once again we would like to thank Harry for doing most of the work on first class Node.js support and Shopify for sponsoring a machine that we will host the workers on.

Now go add your Node.js projects to travis-ci.org and tell your friends and colleagues about it!

<3 <3 <3, the Travis CI core team.

Discuss on Hacker News

You can discuss Node.js support on travis-ci.org on Hacker News.

VM environment upgrade, Oct 31st, 2011

2011-10-31T00:00:00-07:00

travis-ci.org Ruby workers were upgraded to provide the following:

Ruby 1.9.3-p0 (final release)
JRuby 1.6.5
Updated Rubinius 2.0 from 2.0.testing branch
Node.js 0.4.12, npm 1.0.18
MongoDB 2.0.1
Riak 1.0.1
ragel
RVM 1.9.2

There is also one more change we want to highlight: we now provide two installations of Rubinius, one in Ruby 1.8 mode and another one in Ruby 1.9 mode. Their RVM aliases are rbx-18mode and rbx-19mode, respectively. For example, to test your gem against Rubinius in both modes, you can use the following list of Rubies in your .travis.yml file:

rvm:
  - 1.8.7
  - 1.9.3
  - jruby
  - rbx-18mode
  - rbx-19mode

Existing aliases for 1.8 mode (rbx and rbx-2.0) are still around and will work.

Rubinius' Ruby 1.9 features support is still a work in progress (it does not support encodings yet, for example) but we encourage Ruby developers to try testing their libraries against Rubinius, in both 1.8 and 1.9 modes. Now it is even easier to do on travis-ci.org.

To get regular updates about travis-ci.org environment upgrades and other developments, follow Travis CI on Twitter and watch our Chef cookbooks repository on GitHub.

A Big Refactoring!

2011-08-29T00:00:00-07:00

We've just rolled out a big refactoring to the Travis CI application (i.e. the server app which runs on Heroku) that we've been working on over the last four weeks.

This refactoring was quite far-reaching and even though we've tried hard to make sure everything works fine there may be glitches and bugs that we've overlooked.

Why?

The motivation behind all of this work was quite manifold. Maybe the best summary is that our previous domain model still had the very basic design from its original spike. But here are some more details. We wanted to achieve the following things:

Split up the monster Build model into more finegrained classes for more clarity
Move to a statemachine-like pattern for more explicitely reflecting various state changes that happen across various models
Lay better grounds for the long planned move to AMQP (communication with the workers)
Lay better grounds for the long planned move Sproutcore (reimplementation of the JS client)
Improve test coverage and move to RSpec (for unifying test technologies and a slightly lower barrier for new devs)
Generally clean up both model and test code.

One major intention was to generally clean up our codebase, complete and improve the test suite and make the model design more readable. Another was to split up the former Build model which had grown into a huge tangled monster. And while we were at it we also wanted to better communicate the fact that the domain model is very much about about triggering state changes through various events and messages.

You can find more information about the new domain model design in this document. Some of the details outlined there haven't been implemented, yet. E.g. the Build model does not have the mentioned errored and cancelled states, the Task::Test does not have cloned and installed states ... simply because the worker does not support triggering these, yet. These things will probably be added in a later stage.

When we reviewed common Ruby statemachine implementations we found none of them do what we needed, so we came up with our own brand of it: simple_states may or may not useful for your own usecase but it does exactly what we need in Travis CI and nothing more.

Another gem that has been implemented in the course of this refactoring is data_migrations. We had quite a bunch of columns to migrate from the builds table to various other tables (such as commits, requests, tasks) and it seemed easier to come up with a simple DSL for that than writing all these queries by hand.

Also, we're now using hashr in the application, too (for Travis.config, specifically). We've used it in the worker code before and it worked pretty well.

In other news ...

In other news, over the last month we have extract a small project that we use to develop our Chef cookbooks and added the following tools to the VM infrastructure:

kerl to support Erlang with testing against multiple OTP releases
leiningen 1.6 for Clojure projects
sbt 0.10 for Scala projects
Thinking Sphinx 0.9.9, 1.10 and 2.0. Riddle and Thinking Sphinx are now hosted on Travis.
RabbitMQ now installs HTTP API plugin

Hello, World

2011-08-20T00:00:00-07:00

puts "Hello, world!"

I think that's required for first blog posts on technical topics.

Now that that's out of the way

Welcome to the first post on the Travis blog! Hopefully we'll end up having a bunch of great content for you here.

We? Who's this 'we'?

Me, of course. Duh. Specifically? I'm Steve Klabnik. I'm heading up the Travis documentation. But this entire website is on GitHub, so if you were so inclined, 'we' could also mean 'you!'

Got a new fun project on Travis? Have you recently added some fun code, or found a new feature useful? Write a post! It's good for you!

Why you should read this blog

I'll also be trying to make posts roughly once a week letting you know what's new in the world of Travis. We've got a bunch of contributors, and lots of exciting stuff going on, so it's hard to keep up! Just check out this blog, it's much easier than reading the commit list. ;)

Oh, and if you want to subscribe via RSS, grab the Travis blog feed here