Code Walhalla ... Avatar

_Why Travis?

_Why?

August 19th 2007, _Why the lucky stiff, anonymous author of “Why’s poignant guide to Ruby” book and various OpenSource project such as Camping, Shoes or hpricot disappear from web radar. Since then August 19th is commemorated every year, all over the world and developers offer their strength, knowledge and will to help building Free content and applications.

This year, in France, Jérémy Lecour offered to host a hacking WE in his place, a charming house on Marseilles’s hills. We met there, during 2 days, with Thibault Barrère and Gregory Colpart, well decided to bring also our small contribution to the OpenSource world.

Travis ?

I started to look into Travis project after RuLu 2011 conference. Sven Fuchs and Josh Kalderimis came to present their idea and invite the french community to use, speak, love or hate Travis-CI application.

Travis-CI is an online testing platform. Easy to plug for any project versionned on Github, Travis-CI automatically triggers a build on a remote server at each commit. Results are returned to you by email, webhook or directly on Travis-CI UI .

So Why Travis?

For all of us, using Rails and building multilingual apps, Sven Fuchs is a Guide. He gave years of its energy and talent to build and maintain I18n’s Ruby Implementation. Today it’s a Rails standard part of the core gems. Starting Travis, Sven jumped on a more ambitious project that might revolutionize our testing approach.

For a mid-size startup or an Opensource team, having a CI server has a coast. Benefices are obvious as it’s a basic step for continuous delivery. You have to install it, tune it, maintain it. Travis-CI, as an easy to implement CI standard, will consequently help our community to increase it’s delivery pace and quality.

So that’s Why, we choose to work during our first Why Day on Travis-CI to deliver a feature requested by Sven and Josh.


Travis internals overview:

Well documented, Travis-CI architecture is nevertheless not trivial. Build to run on the cloud, using multiple third Party apps/api like Pusher App, Redis to Go, Heroku and using Edge technologies like Backbone.js, God, Resque or Vagrant, even if well coded, it’s not the kind of app you fully deploy locally just running bundle install & thin start.




As a matter of fact, entry ticket is expensive.

Installing Travis-CI locally:

Pre-requisites:
- RVM
- Postgres
- VirtualBox 4.0.6
- Vagrant 0.7.7
- Redis server

When all those components are installed, you’ll have to clone 3 repos: travis-ci and travis-worker and travis-cookbook.

Travis-worker is the lib running in your testing box able to communicate with the Job Queue and launch builds. 

The second repo contains Vagrant recipes to build your boxes with a full ruby stack (from mysql to reeds including risk, sphinx and much much more).

Load travis-worker submodule (Vagrant Chef recipes) with:

git submodule update —init


Then get a basic Lucid box, configure your worker and build your Vagrant boxes and workers with:

wget http://files.vagrantup.com/lucid32.box
cp ./config/worker.example.yml ./config/worker.development.yml
thor travis:worker:vagrant:rebuild


Travis-ci is the central rails app, receiving Github webhooks, adding job to Redis Queue, displaying build results. Before installing, gather following infos to update your travis.yml config file:

  • local redis URL (http://localhost:6379)
  • pusher App credential (not mandatory in fact)
  • github OAuth credential (create an app on github application page)

Install travis-ci as an usual Rails app:

gem install bundler thin
cp ./config/travis.example.yml ./config/travis.yml
bundle install
rake db:create db:migrate db:seed
thin start

Here you are. You have your own local travis-ci app running on http://localhost:3000.

Playing with Travis Build:

The ticket we were working on was related to Build automatic tagging. However build cannot be triggered as long as your travis-ci app is on local IP. This can be done manually using webhooks. For this you’ll have to POST a payload.json file to http://localhost:3000/builds.

Here is a payload.json example and the associated ruby script to launch it written by @jlecour and based on a simple ruby forked project “Boolean”:

{
    “before”: “”,
    “after”: “”,
    “ref”: “refs/heads/master”,
    “repository”: {
        “url”: “https://github.com/hakanensari/boolean”,
        “name”: “boolean”,
        “description”: “An object that represents truth”,
        “watchers”: 5,
        “forks”: 2,
        “private”: false,
        “owner”: {
            “email”: “hakan.ensari@papercavalier.com”,
            “name”: “hakanensari”
        }
    },
    “commits”: [
        {
            “id”: “45026941e67fb9392f9d28c3685d5f47ac454f86”,
            “url”: “https://github.com/hakanensari/boolean/commit/45026941e67fb9392f9d28c3685d5f47ac454f86”,
            “author”: {
                “email”: “hakan.ensari@papercavalier.com”,
                “name”: “Hakan Ensari”
            },
            “message”: “first commit “,
            “timestamp”: “2011-08-19T05:39:05-07:00”,
            “added”: [
                “.gitignore”,
                “.travis.yml”,
                “Gemfile”,
                “README.md”,
                “Rakefile”,
                “boolean.gemspec”,
                “lib/boolean.rb”,
                “lib/boolean/version.rb”,
                “test/boolean_test.rb”
            ]
        }
    ]
}

To trigger it you can use the following ruby script:

require ‘net/http’
require ‘uri’
payload = File.read(‘~/rails/apps/travis-worker/payload.json’)

url = URI.parse(‘http://localhost:3000/builds’)
req = Net::HTTP::Post.new(url.path)

req.basic_auth ‘jack’, ‘pass’
req.set_form_data({‘payload’=> payload}, ‘;’)
res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
case res
when Net::HTTPSuccess, Net::HTTPRedirection
  puts ‘OK’
else
  res.error!
end

Replies

Likes

  1. vzmind posted this

 

Reblogs