Building Vagrant Boxes with VeeWee on TravisCI

by on December 5, 2012 1:21 pm

(Pro Tip: you can safely skip the first 3 paragraphs)

We’ve all been there: You push some .travis.yml commits and your clone gets parachuted into VM Land – only to find that things don’t go quite as expected. As the credits roll, you can’t help but feel a little anger towards your clone. How could it just blindly follow the script when things went wrong and not even try to improvise or troubleshoot? You wonder – how can I get a Pastrana-level of confidence before I push that clone out the door?

How can I run the Travis box locally, before I push my commits? (Let’s pretend I didn’t just spend days investigating this and then just now find a blog entry from 3 months ago which had a more polished solution for most of this topic and then I had to switch gears at the last minute and only cover an obscure corner of the topic, mmmkay? Embarrassed but undeterred, I move forward…)

We will continue by reviewing the original problem I faced that drove me to explore running a Travis box locally. You will probably never run across the problem. But hey – at least it’s unlikely that someone has already blogged about this topic!

The Goal: I wanted to build Vagrant boxes with VeeWee on TravisCI.

Q: Why run VeeWee on Travis? A: The transparency offered by Travis would allow people to trust the published binaries. The binary boxes would be published by Travis at the end of the build to the GitHub repo’s “download” section.

So, I started by proving out that I could run VirtualBox inside Travis - https://travis-ci.org/veewee-community/travis-vagrant-up/builds/3427898/#L293 (compare the before/after directory listings).

Encouraged, I continued.

I added VeeWee to the mix, and ran into this:

It kept sticking on the “Starting a webserver :7122″ line until the Travis time limit kicked in and stopped the build. Either the step was legitimately taking too long or there was some kind of error that didn’t show up in the log. What was the build trying to tell me? I needed to get inside the box’s head. But wait, the box had no head – it was headless.

Lending Travis a helping head:

I needed to run Travis locally and see what might be trying to pop up on the GUI. So, I started by upping this Vagrantfile:

(coffee break: that Vagrant box download is over 3 gig)

After studying Travis’ GUI testing documentation, I SSHed-in to my newly upped box and ran some stuff to enable a virtual X session and publish it over VNC. I also enabled a applet-based browser-view of the VNC session:

Then, I started running the commands from my .travis.yml file:

Once I ran the “veewee vbox build” command, it just sat there. I browsed to the virtual X session in my browser and watched to see what popped up. Ah, finally I was getting somewhere:

vbox-warning

I spun my wheels for a while thinking I needed to fork VeeWee and suppress the warning to continue the build process, but ran into a snag revealed by the VirtualBox code:

Translation: no “pcszAutoConfirmId” means no way to suppress! Actually, it didn’t matter that I couldn’t suppress the message because the VM really couldn’t have run anyways – here’s what happens if I actually select “continue” to proceed past that dialogue:

it_refuses

I was so dumb because when I first did the proof-of-concept for running VirtualBox in Travis, Vagrant upped a 32-bit box, and now I was trying to create a 64-bit box. Well, the Travis box is 32-bit (for now) and VirtualBox has decided not to offer nested VT. (Nested VT, afaik, would allow the 64-bit inside 32-bit scenario) Bummer.

So, I changed the VeeWee template choice to request a 32-bit box… Hoorah! After 65 minutes the Vagrant box was all built. But when I ran it in the actual Travis service instead of locally, this is what I saw:

Oh well, it timed out! But at least it got past the earlier snag and would have built given enough time. I’m not complaining though, I can completely understand the reasoning behind the time limits Travis enforces. A 65 minute build on a free Travis account type is a burden on the other people trying to build stuff.

So, that’s where I got stuck. I’m just glad I didn’t actually promise you a real solution, in which case you might have been angry at me. Thanks.

– Luke Patterson, asktheteam@keyholesoftware.com

  • Share:

Leave a Reply

Things Twitter is Talking About
  • @rickincanada Thx for your tweet! Shoot us an email at asktheteam@keyholesoftware.com so we can set up a time to talk. Have a good day.
    July 24, 2014 at 3:33 PM
  • Never used JAXB? Check out a simple usage pattern that pairs #JAXB’s data binding capabilities with JPA - http://t.co/Ki9G04HV5e
    July 24, 2014 at 9:53 AM
  • Guess what today is? Tell An Old Joke Day - http://t.co/835ORWMX6N! So, why do programmers always confuse Halloween & Xmas? 31 Oct = 25 Dec
    July 24, 2014 at 8:45 AM
  • MT @midwestio: Posted another #midwestio talk recording to our YouTube channel: @MinaMarkham on modular CSS. Watch: http://t.co/aU3LpfUoi4
    July 24, 2014 at 8:25 AM
  • We just posted pictures from our National Hot Dog Day Lunch Cookout. Check them out - http://t.co/To06plaw1C
    July 23, 2014 at 4:14 PM
  • Good free cheat sheet - #Java Performance Optimization Refcard from @DZone: http://t.co/7vBgsmqy08
    July 23, 2014 at 10:48 AM
  • Did you know today is a holiday? It's National Hot Dog Day! We're gearing up for our team lunch hot dog cookout & can't wait to celebrate.
    July 23, 2014 at 9:43 AM
  • Check out our newest blog: #JAXB – A Newcomer’s Perspective, Part 1 http://t.co/Ki9G04HV5e
    July 22, 2014 at 1:22 PM
  • New post on the Keyhole blog by Mark Adelsberger: #JAXB – A Newcomer’s Perspective, Part 1 http://t.co/Ki9G04HV5e
    July 21, 2014 at 2:27 PM
  • If you're a Java dev, you're likely familiar with Annotations. But have you created your own #Java Annotations? Ex - http://t.co/BgCsYjxZKF
    July 18, 2014 at 12:10 PM
  • RT @gamasutra: Don't Miss: Unconventional Tips for Improving your Programming Skills http://t.co/6TFox7CKHU
    July 16, 2014 at 3:20 PM
  • We're about to send out our free monthly tech newsletter. Dev tips/articles via email. Not on the list yet? Sign up - http://t.co/F8h0NSiicZ
    July 15, 2014 at 11:57 AM
  • Have you ever tried creating your own #Java annotations? See a situation where it was beneficial - http://t.co/BgCsYjxZKF
    July 15, 2014 at 8:36 AM
  • There's a new post on the Keyhole blog by @jhackett01: Creating Your Own #Java Annotations - http://t.co/BgCsYjxZKF
    July 14, 2014 at 1:43 PM
  • We love development! Have you seen our weekly team blog? We show how to be successful with the tech we use. See it - http://t.co/nlRtb1XNQH
    July 12, 2014 at 2:35 PM
  • Rapid appdev has a bad rep, but there are ways to bring development time down the right way. Don't Fear the Rapid - http://t.co/aTPcAKOj0r
    July 11, 2014 at 3:10 PM
  • Automated Testing is great for dev, but does bring a set of challenges (especially for #agile teams). Success tips: http://t.co/1acl1ngO7i
    July 11, 2014 at 12:16 PM
  • This is fantastic - One small step for Google, one giant leap for empowering girls to code: http://t.co/R90V5DBkv1
    July 10, 2014 at 2:52 PM
  • #RabbitMQ: messaging software built on AMQP protocol. Learn relevant concepts & how to avoid common "gotchas" here: http://t.co/ZwMXlhKyX8
    July 10, 2014 at 9:31 AM
  • A huge welcome to Brian Wetzel who joins the Keyhole team today!
    July 10, 2014 at 8:50 AM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.