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 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.

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.

MK

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 fine-grained classes for more clarity
• Move to a statemachine-like pattern for more explicitly 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 use case 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

Over the last month we have extracted 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