Travis is an attempt to create an open-source, distributed build system for the Ruby community that:
1. allows open-source projects to register their repository and have their test-suites run on demand
2. allows users to contribute build capacities by connecting a VM that runs a build agent somewhere on their underused servers
If you are interested in Travis please subscribe to the Google group and check out my introductional blog post over here: Travis – a distributed build server tool for the Ruby community
Travis consists of four main parts:
- A Backbone.js single-page application that runs client side.
- A Rails 3 application that serves to the in-browser application and takes pings from Github.
- A Resque worker for running a project’s test suite remotely.
- A websocket server for tailing build results to the browser. (This server is currently started within the Rails app process.)
To get an idea: 1:20 quick demo screencast
- Get a working application up and running that can distribute build requests to manually installed build workers and report back to browsers. Most simplistic UI that ever would make sense for this. Have a restricted set of allowed Github repositories.
- Allow people to login through Github OAuth and somehow maintain a list of repositories they’re interested in.
- Create VM images so that people can easily install and start build workers on underused or contributed servers.
This code is a spike and everything will change very likely. It is here to try out a few basic concepts and building blocks and ask people to share their opinion.
Nonetheless we currently have a working demo application running on http://travis-ci.org which uses
- RedisToGo as a Redis store
- Pusher as a Websocket server
- A virtual server lent by Avarteq for running a Resque worker.
Each of these components could be replaced with something else, e.g. one could easily use a different Redis server.
Signup is easy, all you need to do is login using Github OAuth2 and an account will automatically be created.
In order to register a project for builds on Travis just supply a Github service hook using the following URL: http://[YOUR_GITHUB_USERNAME]:[YOUR_TRAVIS_TOKEN]@travis-ci.org/builds
You can get a Travis token on the Travis profile page after signing up.
By default Travis will try to run bundle install and then rake to run yours tests, but if you require a different command to be run to start your tests you can check in a .travis.yml file to specify a custom build script.
See this file used by svenfuchs/routing-filter as an example.
By default Travis will send notification emails to everyone involved in the project on GitHub. You can specify who receives emails in `.travis.yml`:
notifications:
recipients:
- sferik@gmail.com
- drnicwilliams@gmail.com
You can disable email notifications:
notifications:
disable: true
If you have any issues, problems, or questions in getting Travis running for your project, you can find us on irc in #travis on freenode.
Please note that this is an experimental installation.
After adding your project to Travis, you can use the status buttons to show the current status of your projects in your README file on Github or your project website.
Your status button is available at the following URL:
http://travis-ci.org/[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME].pngSo, when using textile, showing your status button (including a link to your Travis project page) is as simple as adding this to your README:
"!http://travis-ci.org/[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME].png!":http://travis-ci.org/[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME]Or if you’re using markdown:
[](http://travis-ci.org/[YOUR_GITHUB_USERNAME]/[YOUR_PROJECT_NAME])Travis’ own status button looks like this:
Please note : GitHub proxies these images so they are delivered over HTTPS via its CDN. Due to this issue there may be a delay until the updated build status is shown on your project page. We are looking into this issue and will update the docs if we find a solution.
To install your own instance of Travis you need to supply various configuration settings:
$ cp config/travis.example.yml config/travis.yml
In order to push these settings to Heroku you can use:
$ rake heroku:config
Starting a local worker:
$ script/worker
Or using God:
$ cp config/resque.god.example config/resque.god $ god -c config/resque.god
Integration tests are implemented using Jasmine and can be run in the browser:
$ RAILS_ENV=jasmine rake db:migrate db:seed $ rails s thin -e jasmine $ open http://localhost:3000
To run the whole test suite simply do:
$ rake test
- Second design Feb 2010
- First design Jan 2010
- Initial mockups of index and details
My first spike was using Nanite for running workers. These materials are now outdated but might be interesting:
- Ruby 1.8.7 or Ruby 1.9.2 (Ruby 1.9.1 is not supported).