Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

  • Blog Navigation
Debugging Travis builds

(Due credit to Trung Lê‘s article on which all this is based)

We recently moved our project’s CI from a TeamCity server onto Travis CI’s new private CI-as-a-service program. We compared several other hosted CI services and found Travis to be the easiest to use, and with the help of Trung’s article also the easiest to debug.

Travis provides all their build worker images as Vagrant boxes available for download. I’d never worked with Vagrant before, but getting it set up is pretty simple. Follow the guide on Vagrant’s page and download the latest version of Vagrant. I’ve found that the boxes that Travis provide right now don’t work with VirtualBox 4.2, and so I’d recommend installing VirtualBox with 4.1 from their ‘older builds’ page.

Once you’re done installing both, you’ll want to install the worker box. The Ruby box is installable via

vagrant box add travis-ruby

This will download and install the VM, which will probably take a few minutes. After that’s complete, initialize the box with

vagrant init travis-ruby

which will create a Vagrantfile for you where you can configure various settings for how Vagrant hosts the VM on your machine. I’ve found it necessary to add

config.ssh.username = "travis"

to get SSH to work properly. After that,

vagrant up
vagrant ssh

will connect you to the box, and verify that things are working properly. If you are prompted for a password upon sshing, it should be travis.

Now you’ll want to either scp your Github SSH key or create a new one and clone your project down to the box. After you have your project, all that remains is to get Travis running.

I haven’t yet figured out how Travis starts from .travis.yml files, so for now we have just created a shell script in which we specify all our Travis setup tasks, put it as the ‘script’ key in our .travis.yml, and then just run it directly on our local box. You can find more info about doing this on the Travis docs page. Aside from working around the .travis.yml, we haven’t seen any other gotchas in simulating the Travis worker process.

Once you’ve successfully gotten your build to run inside the Vagrant box, you can follow the instructions on Vagrant’s site to repackage your customized Travis worker and share it with the rest of your team.

  1. Travis Grathwell says:

    I think Travis changed the architecture of their boxes from 32 to 64 bit but the file hasn’t been updated accordingly.

    This bit me when I tried to install the 32-bit version of PhantomJS 1.8.2 in the before_script phase, which worked in the VM but failed on actual-Travis.

    I’m sure there’s an updated .box file out there somewhere, but Travis makes it hard to determine how these boxes are built without digging deep into every one of their Github projects.

  2. JR Boyens says:

    Travis no longer uses Vagrant (BlueBox now). So these boxes are unmaintained if you ever happen to find one. The current (2014-2-18) advice is to jump on IRC and ask to get access to your “box” and debug there.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *

Share This